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- PARTE I -DEFININDO O GERENCIAMENTO DE 

PROJETOS 



INTRODUÇÃO 


66 

O tempo não espera por ninguém, e em nenhum outro lugar isso è tão real quanto no gerenciamento de projetos. ” 

Jim MacTntyre 

Para atender a demandas de maneira eficaz, em um ambiente caracterizado pela velocidade das 
mudanças, torna-se indispensável um modelo de gerenciamento baseado no foco em prioridades e 
objetivos. Por essa razão, o gerenciamento de projetos tem crescido de maneira tão acentuada no 
mundo nos últimos anos. O Project Management Institute, juntamente com a Economist Intelligence 
Unit, realizou uma pesquisa sobre o universo dos projetos e constatou que cerca de 12 trilhões de 
dólares são hoje empregados em projetos. Isso significa aproximadamente 25% de toda a economia 
mundial, empregando mais de 20 milhões de profissionais em atividades relacionadas à liderança e 
ao gerenciamento de projetos. Isso confirma o que TomPeters apresentou em seu artigo “\ócê é o seu 
Projeto” em 1999. Ele afirmou que, nos próximos 20 anos, todo o trabalho será desenvolvido por 
meio de projetos. Pouco mais de 10 anos depois essa realidade é evidentemente comprovada. David 
Cleland também afirma que, no futuro, o gerenciamento de projetos será utilizado para gerenciar as 
mudanças em todas as infraestruturas sociais em todos os países, desenvolvidos ou não. 
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Figura 1.1 - Evolução mundial dos membros do PMI no mundo (compilado de PMI Today “Fact Sheet”, Project Management 
Institute, 2002 a 2009) 

Por que isso? A maioria das pessoas mal informadas pode correr o risco de ver o gerenciamento de 
projetos como mais uma “moda” gerencial, proposta por algum desses gurus da administração 
moderna. Nada disso. Na realidade, o gerenciamento de projetos não propõe nada revolucionário e 
novo. Sua proposta é estabelecer um processo estruturado e lógico para lidar com eventos que se 
caracterizam pela novidade, complexidade e dinâmica ambiental. Hoje, por mais que tenhamos 
evoluído tecnicamente, deparamo-nos comum ambiente que evoluiu muitas vezes mais, ou seja, hoje 
somos muito mais capazes que no passado, porém, esse nosso aumento de capacidade é cada vez 
menor se comparado com o aumento na dinâmica do ambiente. Precisamos, portanto, desenvolver 



mecanismos que reduzam essa diferença entre homem e ambiente. 



Figura 1.2 - Evolução comparativa homem-ambiente. 

Outro fator que impulsiona o gerenciamento de projetos é o crescimento da competitividade. Quem 
for mais rápido e competente certamente conseguirá melhores resultados. Na área de tecnologia, isso 
é extremamente claro. Alterações tecnológicas, que anteriormente levavam décadas para serem 
implementadas por completo, hoje tomam apenas algumas horas, em um nível de complexidade 
altíssimo. Cada vez mais, o gerente cumpre o papel de administrador dessas mudanças. Administrar a 
rotina de trabalho, agora, já não é fator diferenciador entre as organizações berne mal sucedidas. 

Diante da pressão desse contexto de mudanças, é preciso que nossas empresas consigam resultados 
com menos recursos, tempo e cada vez mais qualidade, ou seja, fazer mais que os concorrentes, 
gastando menos. A competição irá continuar a pressionar para que melhores ideias e processos sejam 
implementados. 



Figura 1.3 - Análise comparativa da complexidade e da dinâmica dos projetos entre 1960 e 2010. 








Como sobreviver em um mundo onde não se sabe exatamente o que vem a ser liderança, 
produtividade ou lucratividade? Agravando esse quadro imprevisível, constata-se que a cultura 
empresarial brasileira nunca destina tempo para planejar e sempre obtém dinheiro suficiente para 
refazer. Qual a saída? 

A grande maioria dos executivos está, hoje, procurando por essa “fórmula do sucesso”. O sucesso, 
porém, não está em seguir cegamente as modernas teorias de administração apresentadas. É preciso 
que se tenha habilidade para gerenciar aquilo que se conhece muito pouco, ou, até mesmo, aquilo de 
que não se conhece nada. Podemos ver no mercado de tecnologia, principalmente na internet e no 
comércio eletrônico, que não existem, absolutamente, padrões, nem para velocidade nem para 
dinheiro. Esse tipo de companhia nunca se valorizou tanto e, hoje, um projeto de comércio eletrônico 
bem sucedido pode até mesmo valer mais do que toda a parafernália organizacional desenvolvida em 
anos por uma empresa. São os novos parâmetros do mercado, onde tudo o que não existe é rotina. 
Tudo é projeto. 



DEFINIÇÃO DE GERENCIAMENTO DE 
PROJETOS 

A ideia de que planejar significa adivinhar o futuro è simplesmente absurda. ” 

Peter Drucker 



1.10 que é um Projeto? 

Nos últimos trinta anos, o mundo tem enfrentado um incrível dinamismo em suas relações intra e 
interempresariais. As empresas passam, agora, a ser reconhecidas por sua flexibilidade, capacidade 
de atender a seus clientes e profissionalismo. Com equipes de trabalho flexíveis, recursos e esforços 
focados nas necessidades organizacionais e planejamento baseado em projetos, as corporações de 
sucesso percebem que o uso dos conceitos de gerenciamento de projetos é universal, genérico, 
rompendo todas as barreiras culturais, nacionais e regionais, onde as necessidades de sobrevivência 
competitiva também são universais. 

O gerenciamento de projetos é um conjunto de ferramentas gerenciais que permitem que a empresa 
desenvolva um conjunto de habilidades, incluindo conhecimento e capacidades individuais, 
destinados ao controle de eventos não repetitivos, únicos e complexos, dentro de um cenário de 
tempo, custo e qualidade predeterminados. 

Para se entender o que é gerenciamento de projetos, é importante que se saiba com clareza o que é 
um projeto. 

Projeto é um empreendimento não repetitivo, caracterizado por uma sequência clara e 
lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e 
definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, 
recursos envolvidos e qualidade. 

Para Cleland, um projeto é uma combinação de recursos organizacionais, colocados juntos para 
criarem ou desenvolverem algo que não existia previamente, de modo a prover um aperfeiçoamento 
da capacidade de desempenho no planejamento e na realização de estratégias organizacionais. 

Já para Meredith, um projeto é uma atividade única e exclusiva com um conjunto de resultados 
desejáveis em seu término. É também complexo o suficiente para necessitar de uma capacidade de 
coordenação específica e um controle detalhado de prazos, relacionamentos, custos e desempenho. 

Nesse contexto, pode-se concluir que projeto é um conjunto de ações, executado de maneira 
coordenada por uma organização transitória, ao qual são alocados os insumos necessários para, em 
um dado prazo, alcançar o objetivo determinado. O conceito de organização transitória está 
diretamente relacionado a um esquema organizacional particular e temporário que somente existe 
para tornar o trabalho com projetos mais eficiente e intuitivo por parte da organização. 

Os projetos atingem todos os níveis da organização. Eles podem envolver uma quantidade pequena 
de pessoas, ou milhares delas. Podem levar menos de um dia ou vários anos. Os projetos, muitas 
vezes, extrapolam as fronteiras da organização, atingindo fornecedores, clientes, parceiros e 
governo, fazendo parte, na maioria das vezes, da estratégia de negócios da companhia. 

Como exemplos de projetos, podem-se citar os seguintes: 

• instalação de uma nova planta industrial; 

• redação de um livro; 

• reestruturação de um determinado setor ou departamento da empresa; 

• elaboração de um plano de marketing e publicidade; 

• lançamento de um novo produto ou serviço; 

• informatização de um determinado setor da empresa; 



• construção de uma casa; 

• realização de uma viagem. 

Como exemplos reais de projetos, podem-se citar os seguintes: 1 

• construção das pirâmides de Gisé 

• construção da muralha da China 

• reconstrução dos campos de petróleo do Kuwait devastados pela Guerra do Golfo; 

• planejamento e preparação para os jogos olímpicos de Sydney e Pequim; 

• preparação para a copa do mundo de futebol em 2014 no Brasil; 

• construção das usinas hidroelétricas de Jirau e Santo Antônio no Rio Madeira (Brasil); 

• desenvolvimento de respostas aos tremores de terra no estado da Califórnia, EUA; 

• campanha presidencial norte-americana; 

• estudo do desastre aéreo do ônibus espacial Challenger; 

• construção do novo edifício do congresso nacional da Austrália; 

• sistema de vigilância da Amazônia (SIYAM); 

• exploração da área de Pré-Sal pela petrolífera brasileira Petrobras. 

Os projetos podem ser aplicados em praticamente todas as áreas do conhecimento humano, incluindo 
os trabalhos administrativos, estratégicos e operacionais, bem como a vida pessoal de cada um. 
Podem-se destacar as seguintes áreas de aplicabilidade como os principais utilizadores da técnica de 
gerenciamento de projetos: 

• engenharia e construção civil; 

• desenvolvimento de programas de computador; 

• estratégia militar; 

• política; 

• administração de empresas; 

• marketing e publicidade; 

• pesquisa e desenvolvimento; 

• manutenção de planta e equipamentos. 


1.2Diferenciando Projetos, Subprojetos, Programas e Portfólios 

Diversas vezes, um projeto necessita ser subdividido em partes, de fácil gerenciamento e controle, 
denominadas subprojetos. Os subprojetos são responsáveis por uma pequena parte do projeto total 
ou por fases extremamente específicas do projeto e podem, na maioria das vezes, ser terceirizadas ou 
desenvolvidas por grupos isolados. Um subprojeto não tem sentido se tratado isoladamente. 
Subprojeto desvinculado de um projeto é como um braço fora do corpo. 

De acordo com o PMI, o termo programa é utilizado para identificar um grupo de projetos 
relacionados que são gerenciados e coordenados de modo integrado, obtendo os benefícios e os 
controles que não existem ao gerenciá-los individualmente. O interesse na estruturação do programa 
é tático. 

Já um portfólio é um conjunto de projetos, programas e outros esforços que são agrupados para 
facilitar o atingimento dos objetivos estratégicos do negócio. Esses componentes (projetos, 
programas e outros esforços) são mensuráveis, ordenáveis e priorizáveis. O interesse na estruturação 
do portfólio é estratégico. 



Figura 2.1 - As áreas de abrangência de portfólios, programas, projetos e subprojetos. 










QUANDO OS PROJETOS SAO 
NECESSÁRIOS? 


O homem razoável se adapta ao mundo, enquanto o homem irracional persiste em tentar adaptar o mundo a si próprio. No entanto, todo o progresso do mundo depende apenas desse homem irracional. ” 


Bemard Shaw 


Em geral, o gerenciamento de projetos pode ser aplicado a qualquer situação onde exista um 
empreendimento que foge ao que é fixo e rotineiro na empresa (ad hoc ). Se o empreendimento é 
único e pouco familiar, é importante que a atividade de gerenciamento de projetos seja intensificada. 
O sucesso da gestão de projetos está intimamente ligado ao sucesso com que as atividades são 
relacionadas e realizadas. A base do sucesso está em identificar e diferenciar o projeto das demais 
atividades desenvolvidas na organização. 

A grande dificuldade está no fato de que a maior parte das pessoas realiza trabalhos rotineiros (plain 
work) e projetos. Frequentemente, atividades de projeto e rotineiras têm as mesmas necessidades 
(reuniões, telefonemas, relatórios, análises) e isso faz com que sua distinção seja ainda mais difícil. 
A diferença básica está nos objetivos. Os projetos possuem metas claras e definidas sendo realizados 
em um período definido de tempo, e não indefinidamente, como os trabalhos rotineiros. 



Figura 3.1 - Todos os projetos são esforços, mas nem todos os esforços são projetos 

Kerzner pondera que diversas pressões externas podem forçar as companhias a adotarem 
gerenciamento de projetos como forma de realizarem seus negócios. São elas as seguintes: 

• competição; 

• padrões de qualidade; 

• redução nas margens de lucro; 





• resultados financeiros; 

• fatores tecnológicos; 

• aspectos legais; 

• aspectos sociais; 

• fatores políticos; 

• pressões econômicas. 

Ao optar pela realização de um determinado projeto, uma organização precisa utilizar diversos 
critérios de seleção para que os objetivos sejam atingidos, garantindo o seu sucesso. A seguir, 
destacam-se os critérios mais importantes: 

• realismo; 

• capacidade; 

• flexibilidade; 

• facilidade de uso; 

• custo; 

• facilidade de informatização. 

Cleland propõe que diversos critérios podem ser aplicados para a consideração do uso dos 
conceitos de gerenciamento de projetos, conforme diagrama a seguir. 


Mudança da Marcado 


Nâo-temlliandade 


Compartihamento de Recursos 



Tamanho do Empreendimento 


InterdependAnda 


Reputação da Organização 


Importãnda do Empreendimento 


Figura 3.2 - Necessidade de gerenciamento de projetos (Cleland). 

No diagrama, sete fatores devem ser analisados para a determinação da necessidade, ou não, do 
gerenciamento de projetos. São os seguintes: 

Tamanho do empreendimento - Mesmo considerando que o tamanho é um assunto relativo, pode-se 
generalizar que empreendimentos que necessitem de uma quantidade de dinheiro, pessoal e tempo 
superior ao normalmente empregado pela empresa se beneficiem diretamente com o gerenciamento 
de projetos. 

Interdependência - Se o esforço requer uma grande interdependência entre os departamentos da 
organização ou entre a cadeia de relações cliente-fornecedor, onde as atividades a serem realizadas 
estão intimamente relacionadas, o gerenciamento de projetos se torna fundamental. 

Importância do empreendimento - Muitas vezes, a força gerencial da empresa não quer que o 
empreendimento esteja sujeito a qualquer tipo de burocracia organizacional que possa resultar em 


perda de resultados para os trabalhos. Empreendimentos que tenham um grande grau de risco e 
incerteza também se beneficiam diretamente com os projetos. 

Reputação da organização - Quando o fracasso no cumprimento de prazos e orçamentos de um 
empreendimento pode prejudicar seriamente a imagem e a reputação da organização, a decisão sobre 
o uso do gerenciamento de projetos é determinante. 

Compartilhamento de recursos - Como os projetos envolvem, normalmente, recursos altamente 
especializados, torna-se necessário um compartilhamento de recursos entre diversos projetos e até 
mesmo entre os projetos e outros trabalhos da empresa, para redução de custos. Quando isso se 
intensifica, o gerenciamento de projetos torna-se a melhor técnica de gerenciamento desses recursos. 

Não-familiaridade - Quando o esforço a ser empreendido é completamente novo e diferente do 
normal, a orientação dos trabalhos a projetos pode ser fundamental. Isso também depende do quanto 
é novo e diferente o esforço. Provavelmente, o desenvolvimento de um novo produto ou serviço deve 
ser encarado como um projeto, enquanto uma alteração em um produto ou serviço pode ser encarada 
como um trabalho convencional, não necessitando de projetos. 

Mudanças de mercado - Várias organizações atuam em mercados extremamente turbulentos, onde as 
modificações tecnológicas e de mercado geram uma necessidade constante de atualização. Nesses 
casos, o gerenciamento de projetos atua facilitando o processo gerencial sem, no entanto, prejudicar 
a flexibilidade e a criatividade organizacionais. 

Na verdade, não é necessário que todos esses fatores sejam favoráveis a projetos para que se possa 
tratar o empreendimento como um projeto. Basta que um desses fatores seja determinante para que 
todo o modelo de gerenciamento de projetos seja necessário. 



características dos projetos 


Clientes compram beneficios, resultados, nunca esforços. ” 


Gregory Githens 

As principais características dos projetos são a temporariedade, a individualidade do produto ou 
serviço a ser desenvolvido pelo projeto, a complexidade e a incerteza. 

Temporariedade significa que todo projeto possui um início e um fim definidos, ou seja, é um evento 
com duração finita, determinada em seu objetivo. Wideman afirma que o ciclo de vida do projeto 
caracteriza a sua temporariedade, partindo de um processo de trabalho estratégico inicial até atingir 
um topo de trabalho executivo de produção que antecede o seu término. 

Individualidade do produto ou serviço produzido pelo projeto, conforme o guia de conhecimento de 
gerenciamento de projetos do PMI, significa realizar algo que não tinha sido realizado antes. Como o 
produto de cada projeto é único, suas características precisam ser elaboradas de maneira 
progressiva de modo a garantirem as especificações do produto ou serviço a ser desenvolvido. 

A partir dessas duas principais características, podem-se descrever as demais. 

• Empreendimento não repetitivo - É um evento que não faz parte da rotina da empresa. É algo 
novo para as pessoas que o irão realizar. 

• Sequência clara e lógica de eventos - O projeto é caracterizado por atividades encadeadas 
logicamente de modo a permitir que, durante a execução, o acompanhamento e o controle sejam 
precisos. 

• Início, meio e fim - Todo projeto respeita um determinado ciclo de vida, isto é, tem uma 
característica temporal. Muitas vezes, o término de um projeto coincide como início de outro. 
Ter início, meio e fim não significa ser longo ou curto em duração. Podem existir projetos de 1 
dia ou de 10 anos. Porém, um projeto que não tem término não é um projeto, é rotina. 

• Objetivo claro e definido - Todo projeto tem metas e resultados bem estabelecidos a serem 
atingidos em sua finalização. 

• Conduzido por pessoas - O cerne fundamental de qualquer projeto é o homem. Sem ele, o 
projeto não existe, mesmo que se disponha de equipamentos modernos de controle e gestão. 

• Projetos utilizam recursos - Todo projeto utiliza recursos especificamente alocados a 
determinados trabalhos. 


• Parâmetros predefinidos - Todo projeto necessita ter estabelecidos valores para prazos, 
custos, pessoal, material e equipamentos envolvidos, bem como a qualidade desejada para o 
projeto. É impossível estabelecer, previamente, com total precisão, esses parâmetros. Todos 
eles serão claramente identificados e quantificados no decorrer do plano do projeto. Entretanto, 
os parâmetros iniciais vão atuar como referências para o projeto e sua avaliação. 

Complementando esses conceitos, Wildeman propõe que os projetos possuem uma série de 
características específicas que necessitam de uma atenção especial, conforme mostra a tabela a 
seguir. 



Característica 

Função 

Raridade 

• A definição dos objetivos do projeto faz com que ele seja único ou 

relativamente pouco frequente 

Restrições 

• Tempo limitado 

• Capital limitado 

• Recursos limitados 

Multidisciplinaridade 

• Os esforços realizados entre áreas diferentes da organização, ou 

entre organizações requerem integração 

• 0 trabalho interdisciplmar necessita de coordenação através dos 

limites organizacionais 

• Diversas habilidades podem requerer coordenação específica 

Complexidade 

• Objetivos divergentes entre as partes envolvidas no projeto 

necessitam de gerenciamento 

• A tecnologia pode ser modificada em métodos e análises 

• A tecnologia pode ser complexa por si mesma 


Tabela 4.1 - Características específicas de projetos, conforme Wideman (1992). 








DEFININDO O SUCESSO DOS PROJETOS 


O sucesso vem para aqueles que fazem com que ele aconteça, não para aqueles que deixam que ele aconteça. ” 


Anônimo 

É de fundamental importância que se saiba o que é um projeto bem-sucedido. Muitas vezes, ao 
avaliar o projeto, a equipe e até mesmo os patrocinadores são levados a analisar apenas partes de um 
conceito muito mais amplo. As questões a seguir são alguns exemplos de aspectos que apenas 
aparentemente indicam resultados de sucesso. 

Algumas questões comuns não necessariamente descrevem o que faz um projeto ser bem sucedido, 
como se tem a seguir. 

• O projeto ficou abaixo do orçamento previsto? 

• O projeto terminou mais rápido? 

• O projeto consumiu menos materiais e pessoas? 

• O cliente foi surpreendido pela qualidade do resultado do projeto? 

Na verdade, nenhuma dessas respostas descreve um projeto bem-sucedido SOB A ÓTICA DE 
PLANEJAMENTO E PROJETO. 


Um projeto bem-sucedido é aquele que é realizado conforme o planejado. 

O sucesso é colher o que se plantou. Nem mais nem menos. Muitas vezes a organização avalia como 
sucesso o fato de um determinado projeto superar o plano, ou seja, consumir menos recursos que o 
previsto. Isso é um erro de percepção, uma vez que, sob a ótica de gerenciamento de projetos, houve 
uma falha no planejamento que permitiu que os recursos fossem superestimados, e não uma vitória ou 
economia. Imagine que uma empresa lance uma campanha publicitária de um novo produto e planeje 
uma venda de 10.000 unidades do produto em uma semana. Após uma semana, foram solicitadas 
1.000.000 de unidades. Isso seria um tremendo sucesso ou um grande problema, uma vez que a 
empresa não tem estrutura e capacidade para atender a tal demanda? 

Guss, por meio de uma revisão bibliográfica detalhada da literatura disponível sobre sucesso de 
projetos, concluiu que menos de 25% dos estudos se propõe a responder à seguinte questão: O que é 
sucesso de projetos? 

Através dos anos, conforme propõe Kerzner, o conceito do sucesso em projeto mudou 
significativamente. Na década de 60, o sucesso de projeto estava vinculado diretamente a termos 
técnicos ou ao funcionamento de um produto ou serviço desenvolvido por ele. Atualmente, o sucesso 
de um projeto pode ser definido através de resultados obtidos no prazo, no custo e na qualidade 
desejados, sem deixar de atentar para outros parâmetros, que podem até mesmo ser chamados de 
sucesso organizacional, descritos adiante. 

Ao se detalharem os quesitos para considerar um projeto como bem sucedido, tem-se a seguinte 
listagem: 

• ser concluído dentro do tempo previsto; 

• ser concluído dentro do orçamento previsto; 

• ter utilizado os recursos (materiais, equipamentos e pessoas) eficientemente, sem 
desperdícios; 



• ter atingido a qualidade e o desempenho desejados; 

• ter sido concluído com o mínimo possível de alterações em seu escopo; 

• ter sido aceito sem restrições pelo contratante ou cliente; 

• ter sido empreendido sem que ocorresse interrupção ou prejuízo nas atividades normais da 
organização; 

• não ter agredido a cultura da organização. 



OEstimulando o Sucesso do Projeto 


Para estimular o sucesso do projeto, várias ações podem ser tomadas pelo gerente de projeto e seu 
time nos âmbitos técnico, organizacional e até mesmo comportamental. 

O sucesso dos projetos também está diretamente relacionado com a capacidade que a organização 
tem de favorecer o ambiente para os projetos, uma vez que muitas vezes o gerente/coordenador do 
projeto não dispõe de autoridade suficiente para influenciar o sucesso dos resultados. 

Essas ações incluem: 

• selecionar corretamente os membros-chave do time do projeto; 

• desenvolver um senso de comprometimento em toda a equipe; 

• buscar autoridade suficiente para conduzir o projeto; 

• coordenar e manter uma relação de respeito e cordialidade com o cliente, os fornecedores e 
outros envolvidos; 

• determinar quais processos precisam de melhorias, especialmente os mais importantes; 

• desenvolver estimativas de custos, prazos e qualidade realistas; 

• desenvolver alternativas de backup em antecedência aos problemas; 

• manter as modificações sob controle; 

• dar prioridade a missão ou meta do projeto; 

• evitar o otimismo ou o pessimismo exagerado; 

• desenvolver e manter estreitas linhas de comunicação informal; 

• evitar um número excessivo de relatórios e análises; 

• evitar excessiva pressão sobre o time durante períodos críticos. 

Tudo isso torna óbvia a necessidade de um perfeito relacionamento entre o gerente do projeto, sua 
linha intermediária e os executantes, para que a execução corra em conformidade com o que foi 
previsto e planejado. Outra característica fundamental é o desenvolvimento da habilidade dos 
funcionários responsáveis pela execução do projeto para reportar corretamente os fatos acontecidos 
aos escalões superiores, de forma que esses possam tomar as providências preventivas ou corretivas 
que se fizerem necessárias. 

Finalmente, é preciso que se compreenda que o sucesso de um projeto não implica que uma 
organização está completamente bem sucedida em relação às fronteiras do gerenciamento de 
projetos. Conforme Kerzner, a excelência em gerenciamento de projetos é definida como um fluxo 
contínuo de sucessos em projetos. 




benefícios do gerenciamento de 

PROJETOS 


Nenhum empreendimento pode ser considerado tão pequeno que não se beneficie do gerenciamento de projetos. ” 


Sunny Baker 

O gerenciamento de projetos proporciona inúmeras vantagens sobre as demais formas de 
gerenciamento, tendo se mostrado eficaz em conseguir os resultados desejados dentro do prazo e do 
orçamento definido pela organização. A principal vantagem do gerenciamento de projetos é que ele 
não é restrito a projetos gigantescos, de alta complexidade e custo. Ele pode ser aplicado em 
empreendimentos de qualquer complexidade, orçamento e tamanho, em qualquer linha de negócios. 

Dentre os principais benefícios, podem-se destacar os seguintes: 

• evita surpresas durante a execução dos trabalhos; 

• permite desenvolver diferenciais competitivos e novas técnicas, uma vez que toda a 
metodologia está sendo estruturada; 

• antecipa as situações desfavoráveis que poderão ser encontradas, para que ações preventivas 
e corretivas possam ser tomadas antes que essas situações se consolidem como problemas; 

• adapta os trabalhos ao mercado consumidor e ao cliente; 

• disponibiliza os orçamentos antes do início dos gastos; 

• agiliza as decisões, já que as informações estão estruturadas e disponibilizadas; 

• aumenta o controle gerencial de todas as fases a serem implementadas devido ao detalhamento 
ter sido realizado; 

• facilita e orienta as revisões da estrutura do projeto que forem decorrentes de modificações no 
mercado ou no ambiente competitivo, melhorando a capacidade de adaptação do projeto; 

• otimiza a alocação de pessoas, equipamentos e materiais necessários; 

• documenta e facilita as estimativas para futuros projetos. 



PRINCIPAIS CAUSAS DE FRACASSO EM 
PROJETOS 


Existe muito mais coisa para ser dita sobre o fracasso. Ele é muito mais interessante do que o sucesso. ” 


Max Beerbohm 

Por que os projetos falham? Mesmo com a grande quantidade de benefícios gerados pelos projetos, 
boa parte deles falha ou não atinge o resultado esperado. Muitas falhas são decorrentes de obstáculos 
naturais ou externos que estão completamente fora do controle da organização e que, muitas vezes, 
somente podem ser minimizados ou evitados através de um gerenciamento de riscos eficiente. São 
eles os seguintes: 

• mudança na estrutura organizacional da empresa; 

• riscos elevados no meio ambiente; 

• mudanças na tecnologia disponível; 

• evolução nos preços e prazos; 

• cenário político-econômico desfavorável. 

Mas a maioria dos insucessos é decorrente de outros tipos de falhas, também chamadas falhas 
gerenciais, que podem perfeitamente ser evitadas, tais como: 

• as metas e os objetivos são mal-estabelecidos, ou não são compreendidos pelos escalões 
inferiores; 

• há pouca compreensão da complexidade do projeto; 

• o projeto inclui muitas atividades e muito pouco tempo para realizá-las; 

• as estimativas financeiras são pobres e incompletas; 

• o projeto é baseado em dados insuficientes, ou inadequados; 

• o sistema de controle é inadequado; 

• o projeto não teve um gerente de projeto, ou teve vários, criando círculos de poder paralelos 
aos previamente estabelecidos; 

• criou-se muita dependência no uso de softwares de gestão de projetos; 

• o projeto foi estimado com base na experiência empírica, ou feeling dos envolvidos, deixando 
em segundo plano os dados históricos de projetos similares, ou até mesmo análises estatísticas 
efetuadas; 

• o treinamento e a capacitação foram inadequados; 

• faltou liderança do gerente de projeto; 

• não foi destinado tempo para as estimativas e o planejamento; 

• não se conheciam as necessidades de pessoal, equipamentos e materiais; 

• fracassou a integração dos elementos-chave do escopo do projeto; 

• cliente/projeto tinham expectativas distintas e, muitas vezes, opostas; 

• não se conhecíamos pontos-chave do projeto; 

• ninguém verificou se as pessoas envolvidas nas atividades tinham conhecimento necessário 




para executá-las; 

• as pessoas não estavam trabalhando nos mesmos padrões, ou os padrões de trabalho não foram 
estabelecidos. 

Muitas vezes também é difícil distinguir entre fracasso, fracasso parcial e sucesso de um 
determinado projeto. Isso implica que o que parece ser fracasso em um determinado ponto do projeto 
pode ser um sucesso sob outro ponto de vista, tornando ainda mais difícil a avaliação dos resultados 
do projeto. 

Cabe, então, ao gerente de projeto e à sua equipe controlar as possibilidades de insucessos 
mencionadas. Não se pode criar a ilusão de que o projeto é algo que não se pode controlar, chegando 
à frustrante definição de projeto proposta por Kerzner de que “gerenciamento de projetos é a arte de 
criar a ilusão de que todos os resultados obtidos pelo projeto foram previamente previstos e 
planejados quando, na realidade, não passaram de uma sequência absurda de pura sorte.” 



MITOS DO GERENCIAMENTO DE 
PROJETOS 


As pessoas podem alterar suas vidas alterando suas atitudes. ” 


William James 

Com o crescimento da utilização dos conceitos de gerenciamento de projetos por parte das 
organizações, diversos mitos sobre gerenciamento de projetos foram superados e substituídos por 
conceitos mais modernos e dinâmicos. Kerzner, após inúmeros relatos de experiências 

organizacionais, propôs, em A busca pela Excelência em Gerenciamento de Projetos ~, novos 
conceitos, que estão listados na tabela que se segue. 


Mitos 

Conceitos Revisados 

Gerenciamento de Projetos requer mais 
pessoas e adiciona custos indiretos à 

empresa 

Gerenciamento de Projetos permite ao 
projeto realizar mais trabalho em menos 

tempo com menos pessoas. 

A lucratividade pode diminuir em 

decorrência dos custos de controle 

A lucratividade irá aumentar devido à 

presença de controle 

0 gerenciamento de projetos aumenta o 
número de mudanças no escopo. 

0 gerenciamento de projetos permite 
maior controle sobre as mudanças de 

escopo. 

0 gerenciamento de projetos cria 
instabilidade organizacional e aumenta os 

conflitos entre departamentos. 

0 gerenciamento de projetos toma a 
organização mais eficiente e melhora 
efetivamente a relação entre os setores 

através do trabalho em equipe 

0 gerenciamento de projetos cria 
problemas. 

0 gerenciamento de projetos possibilita a 
solução de problemas. 

Somente grandes projetos necessitam de 
gerenciamento. 

Todos os projetos se beneficiam 
diretamente do gerenciamento de 

projetos. 

0 gerenciamento de projetos cria 
problemas de poder e autoridade. 

0 gerenciamento de projetos reduz os 
conflitos por poder. 

0 gerenciamento de projetos tem como 
objetivos os produtos. 

0 gerenciamento de projetos tem como 
objetivo as soluções. 

0 custo do gerenciamento de projetos 
pode tomar a companhia menos 

competitiva 

0 gerenciamento de projetos aprimora os 
negócios da empresa. 


Tabela 8.1 


Transição de conceitos de gerenciamento de projetos 













QUESTÕES PARA REVISÃO 


1. O que diferencia um projeto de outros esforços? 

2. Por que o gráfico com a análise comparativa da complexidade e da dinâmica dos projetos ao 
longo das décadas justifica o crescente emprego do gerenciamento de projetos nos negócios? 

3. Quais as características que tornam um projeto único? 

4. Por que, mesmo com uma série de benefícios visíveis, a maioria dos projetos ainda não pode 
ser considerada bem sucedida? 

5. Como a organização pode estimular e favorecer o sucesso dos projetos? 

6. Por que sob a visão de projetos, sucesso está vinculado ao cumprimento do plano e não está 
vinculado ao ato de superar o plano? 

7. Como a informação histórica pode favorecer o sucesso dos projetos? 

8. Explique as características de multidisciplinaridade nos projetos. 

9. Forneça cinco exemplos atuais de projetos reais. 

10. Quais são os critérios que podem ser aplicados ao avaliar a viabilidade do uso dos 
conceitos de gerenciamento de projetos em uma determinada necessidade? 

11. Qual é a diferença entre projeto, subprojeto e programa? 
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Conceitos Básicos de Projetos 



Horizontais 

4. Uma realidade atua 

6. Vários projetos reundos 
e mu m co n junte 

7. Exemplo de áiea de 
apicabüdadedo gerenciamento 
de projetos 

8. Não é um projeto 

9. Exemplo de forma de pressào 
externa para utilização do 
gerenciamento de projetos 

10. Característica quedetennnao 
produto únicodo projeto 


_ Verticais _ 

1. Está direta mente 
relacionado ao 
sucesso do projeto 

2. Não está reiaconado 
ao sucesso do projeto 

3. Caracteristes 
fundamental de um 
projeto 

5. Sua falta favorece c 
fracasso do projeto 


twxaa c sx*l ei-or-e ao . 














































































































- PARTE n-0 CICLO DE VIDA DE UM PROJETO 



1. CICLO DE VIDA DE UM PROJETO 


Todo projeto pode ser subdividido em determinadas fases" de desenvolvimento. O entendimento 
dessas fases permite ao time do projeto um melhor controle do total de recursos gastos para atingir as 
metas estabelecidas. Esse conjunto de fases é conhecido como ciclo de vida. O ciclo de vida 
possibilita que seja avaliada uma série de similaridades que podem ser encontradas em todos os 
projetos, independentemente de seu contexto, aplicabilidade ou área de atuação. 

O ciclo de vida pode ser dividido em um conjunto de fases, normalmente fixas para todos os tipos de 
projeto, contendo uma série de passos principais do processo de contextualizar, desenhar, 
desenvolver e colocar em operação uma determinada necessidade do projeto. Essas fases, por sua 
vez, são subdivididas em estágios, ou etapas específicas, de cada natureza de projeto (construção, 
desenvolvimento de produtos, etc.). Esses estágios são, então, subdivididos em atividades, ou tarefas 
específicas de cada projeto. 

Genérico para 
todos os 
projetos 


Espedfoos 
da natureza 
do projeto 


EspEÒidOS 
de cada 
projeto 




Figura 1.1 - Visão do ciclo de vida do projeto 

Conhecer as fases do ciclo de vida proporciona uma série de benefícios para quaisquer tipos de 
projetos. Dentre eles, podem ser destacados os seguintes: 

• a correta análise do ciclo de vida determina o que foi, ou não, feito pelo projeto; 

• o ciclo de vida avalia como o projeto está progredindo até o momento; 

• o ciclo de vida permite que seja indicado qual o ponto exato em que o projeto se encontra no 
momento. 

Ao longo do ciclo de vida, diversas considerações podem ser feitas, principalmente, 

• as características do projeto tendem a mudar com a conclusão de cada fase do projeto; 

• a incerteza relativa aos prazos e custos tende a diminuir com o término de cada fase. 

A descrição do ciclo de vida do projeto pode ser genérica, representada por um único gráfico, ou 
detalhada, incluindo vários gráficos, fluxogramas e tabelas, específicos de cada atividade. 

Com relação à velocidade de desenvolvimento, Meredith afirma que o ciclo de vida dos projetos 
pode ser caracterizado, na maioria das vezes, por um início lento seguido de um progresso acelerado 
até atingir um pico e, logo em seguida, um desaceleramento até atingir seu término. 

















Figura 1.2 - Ciclo de vida do projeto segundo critérios de velocidade de desenvolvimento. 

Outra consideração a ser analisada no ciclo de vida do projeto é o nível de esforço. O nível de 
esforço destinado ao projeto inicia-se em praticamente zero e vai crescendo até atingir um máximo e, 
logo após esse ponto, reduz-se bruscamente até atingir o valor zero, representante do término do 
projeto. Entende-se por esforço a quantidade de pessoas envolvidas no projeto, o dispêndio de 
trabalho e dinheiro com o projeto, as preocupações, as complicações, as horas-extras etc. A 
localização do valor máximo do gráfico pode variar de projeto para projeto. No entanto, esse 
máximo de esforço sempre vai existir em algum momento do projeto. A suavidade desse ponto de 
esforço máximo está diretamente relacionada à qualidade com que o planejamento foi realizado. 
Quanto melhor é o plano, mais suave é a transposição do ponto de esforço máxmo. 



Figura 1.3 - Variação do esforço com o tempo para o projeto. 







CARACTERÍSTICAS DO CICLO DE VIDA 


A maioria dos ciclos de vida dos projetos compartilha algumas características comuns, representadas 
a seguir. 



1.4Potencial de Adicionar Valor ao Projeto 


O potencial de adicionar valor a um projeto é, obviamente, alto no início do projeto, quando a 
maioria das definições ainda está no papel, caindo até o término do projeto, quando o potencial de 
adicionar valor ao projeto tende a ser mínimo. 



Figura 2.1 - Potencial de adicionar valor ao projeto em função do desenrolar do projeto. 





1.5Custo das Mudanças ou Correções 


O custo de promover mudanças no projeto é pequeno nas fases iniciais, crescendo exponencialmente 
com o progresso do projeto até chegar ao seu custo total, podendo até mesmo superá-lo. 



Figura 2.2 - Custo das mudanças / correções em função do desenrolar do projeto. 





l.óOportunidade Construtiva x Intervenção Destrutiva 


Conforme proposto por Wideman, ao se sobrepor o gráfico de potencial de adicionar valor ao 
gráfico de custos de mudança, pode se detectar que, nos momentos em que a curva do potencial de 
adicionar valor supera os custos de correção, tem-se o momento de oportunidade construtiva, quando 
as mudanças são vantajosas para o projeto. Quando a curva de potencial de adicionar valor é inferior 
à de custos de correção, tem-se um cenário de intervenção destrutiva, uma vez que os recursos gastos 
para mudar superam o potencial de adicionar valor ao projeto. 

A conclusão obtida com a análise do gráfico é de que os momentos iniciais do projeto são os mais 
favoráveis à criatividade e à mudança, uma vez que o cenário é de oportunidade construtiva. De 
modo oposto, os momentos finais do projeto são fortemente desfavoráveis a novas ideias e 
criatividade relacionadas aos processos de mudança, salvo nas mudanças corretivas diretamente 
relacionadas ao término dos trabalhos. 



Figura 2.3 - Oportunidade Construtiva x Intervenção Destrutiva 

































1.7Capacidade de Adequação 


A capacidade de adequação do projeto a novas necessidades, ou seja, a capacidade de se alterarem 
as características finais do projeto é grande no início, caindo gradativamente como passar do tempo. 
Quanto mais o projeto se desenvolve, menor é a capacidade de adequação. 



Figura 2.4 - Capacidade de adequação do projeto a novas tecnologias em função do seu desenrolar 






1.8Incerteza do Risco x Quantidade Arriscada 


Ao se comparar a incerteza do risco com a quantidade arriscada, tem-se que, no início do projeto, o 
nível de incerteza é elevado, porém a quantidade arriscada é pequena, uma vez que se está em uma 
fase inicial do projeto. Com seu desenrolar, a incerteza a respeito do risco diminui enquanto a 
quantidade arriscada aumenta, já que o projeto se encontra em fase avançada de execução. O período 
mais crítico é o período de transição, quando se tem o mais alto impacto do risco (maior produto 

probabilidade x quantidade arriscada)-, considerando que o impacto do risco pode ser dado como o 
produto da incerteza do risco pela quantidade arriscada. Essa região coincide exatamente com o 
ponto máximo de esforço na relação esforço x tempo, descrita anteriormente, indicando que o pico de 
esforço está, exatamente, na região de maior impacto dos riscos. 



Figura 2.5 - Análise comparativa da incerteza dos riscos com a quantidade arriscada 






















AS FASES DO CICLO DE VIDA DO 
PROJETO 


As fases do ciclo de vida do projeto dependem, intimamente, da natureza do projeto. Um projeto é 
desenvolvido a partir de uma ideia, progredindo para um plano, que, por sua vez é executado e 
concluído. Cada fase do projeto é caracterizada pela entrega, ou finalização, de um determinado 
trabalho. Toda entrega deve ser tangível e de fácil identificação, como, por exemplo, um relatório 
confeccionado, umcronograma estabelecido ou um conjunto de atividades realizado. 

Genericamente, o ciclo de vida de um projeto pode ser dividido em fases características, conforme 
ilustrado a seguir. 



Figura 3.1 - O ciclo de vida do projeto subdividido em fases ou Grupos de Processo (PMBOK® Guide) característicos 

Cada fase ou grupo do projeto normalmente define 

• qual é o trabalho técnico que deve ser realizado; 

• quem deve estar envolvido. 

O número de fases em um projeto é uma função de sua natureza, podendo variar entre quatro e nove 
fases características. Diversas entidades, como o Departamento de Defesa dos Estados Unidos 
(DOD), a Agência Aeroespacial Americana (NASA), o Project Management Institute (PMI) e 
vários autores desenvolveram sua própria estratificação do projeto em fases, porém todas elas 
abrangem, aproximadamente, a mesma gama de atividades. Para efeito didático, serão consideradas 
apenas cinco fases características. Essas cinco fases também são denominadas grupos de processos 
pelo PMBOK® Guide. 







Fase de Iniciação - É a fase inicial do projeto, quando uma determinada necessidade é identificada e 
transformada em um problema estruturado a ser resolvido por ele. Nessa fase, a missão e o objetivo 
do projeto são definidos, os documentos iniciais são confeccionados e as melhores estratégias são 
identificadas e selecionadas. 

Fase de Planejamento - É a fase responsável por detalhar tudo aquilo que será realizado pelo 
projeto, incluindo cronogramas, interdependências entre atividades, alocação dos recursos 
envolvidos, análise de custos, etc., para que, no final dessa fase, ele esteja suficientemente detalhado 
para ser executado sem dificuldades e imprevistos. Nessa fase, os planos de escopo, tempo, custos, 
qualidade, recursos humanos, comunicações, riscos e aquisições são desenvolvidos. 

Fase de Execução - É a fase que materializa tudo aquilo que foi planejado anteriormente. Qualquer 
erro cometido nas fases anteriores fica evidente durante essa fase. Grande parte do orçamento e do 
esforço do projeto é consumida nessa fase. 

Fase de Monitoramento e Controle - É a fase que acontece paralelamente às demais fases do 
projeto. Tem como objetivo acompanhar e controlar aquilo que está sendo realizado pelo projeto, de 
modo a propor ações corretivas e preventivas no menor espaço de tempo possível após a detecção 
da anormalidade. O objetivo do controle é comparar o status atual do projeto com o status previsto 
pelo planejamento, tomando ações preventivas e corretivas em caso de desvio. 

Fase de Encerramento - É a fase quando a execução dos trabalhos é avaliada através de uma 
auditoria interna ou externa (terceiros), os documentos do projeto são encerrados e todas as falhas 
ocorridas durante o projeto são discutidas e analisadas para que erros similares não ocorram em 
novos projetos. Muito conhecida como Fase de Aprendizado. 

Uma análise direta do gráfico mencionado anteriormente não é conclusiva quanto à interdependência 
e sobreposição de fases no projeto. Na verdade, como desenrolar do projeto, praticamente todas as 
fases e grupos de processo são realizadas quase que simultaneamente, constituindo um ciclo, como é 
mostrado na figura a seguir. 



Figura 3.2 - Inter-relacionamento entre as fases/grupos de processo em um projeto (PMI, 2008) 

Sob outro aspecto, pode-se considerar que a realização de uma fase do projeto é também um projeto 
e, portanto, possui um determinado ciclo de vida e pode ser subdividida em fases. Isso significa que 
existe uma iniciação da fase de iniciação, um planejamento da fase de iniciação, uma execução e um 



controle da fase de iniciação e uma finalização da fase de iniciação, partindo, então, para a iniciação 
do planejamento, etc., como pode ser visto na figura a seguir. 



Figura 3.3 - Fase de execução detalhada em seu próprio ciclo de vida 

O PMBOK também evidencia esse inter-relacionamento entre as fases de uma maneira bastante clara 
e intuitiva, representando, em um mesmo gráfico, os ciclos de vida de todas as fases do projeto. 



Figura 3.4 - Sobreposição das fases em um projeto 



INTEGRAÇÃO ENTRE DESEMPENHO, 
CUSTO E TEMPO EM PROJETOS 


Em todo projeto existe uma relação estreita entre os fatores de desempenho ou performance (escopo 
e qualidade), custo e tempo. Isso quer dizer que é impossível predeterminar todos os fatores 

r 

simultaneamente. E preciso que, com base em dois fatores, se determine o terceiro como uma 
função interna do projeto, ou seja, o máximo que se pode fazer é predeterminar dois fatores e 
calcular o terceiro como uma função dos dois anteriores. Em geral, é necessário que se conheçam, 
detalhadamente, dois fatores e o escopo do projeto para que se determine o terceiro fator, fechando 

todo o cenário PCT do projeto. 

Projeto = f(P,C,T) 

P = f(C, V 
C = f(P, T) 

_ T = f(P, C) _ 

onde P = Desempenho (Performance) 

C = Custo 
T = Tempo 

No desenvolvimento de cada projeto, é inevitável se deparar com a inter-relação entre desempenho 
(escopo e qualidade), custo e tempo em um determinado escopo, que define aquilo que será, ou não, 

r 

abrangido pelo projeto, isto é, as necessidades que serão, ou não, atendidas pelo projeto. E 
impossível desenvolver um projeto que tenha um escopo de aplicabilidades ilimitado. 



Figura 4.1 - Relacionamento entre os fatores desempenho, custo e tempo para um determinado projeto 

Shtub afirma que a importância de cada um desses fatores é dada pela natureza do projeto, podendo 
um fator ter, ou não, mais importância que os demais devido às características e ao objetivo do 
projeto específico, como é mostrado a seguir. 










Projeto A 


Projeto B 




Desempenho 

( 60 , 0 %) 


Figura 4.2 - Importância relativa entre os fatores desempenho, custo e tempo em projetos diferentes 

De modo a facilitar a análise dos fatores, é preciso que se fixe um deles, transformando a relação 
tridimensional em uma relação bidimensional, de fácil entendimento. 



Figura 4.3 - Plano desempenho-custo destacado para um tempo fixo C 

Ao se consideraremos relacionamentos dois a dois têm-se três planos de relacionamento, a saber: 

• custo e tempo; 

• desempenho e tempo; 

• desempenho e custo (mostrado na figura anterior). 

A seguir, cada um desses relacionamentos será analisado, procurando-se evidenciar os “pontos 
ótimos” de relacionamento. Os gráficos que se seguem são ilustrativos e cobrem a maioria dos 
projetos. Contudo, podem existir projetos que não tenhamos comportamentos aqui colocados. 













1.9Análise do Custo x Duração do Projeto 



Figura 4.4-Evolução do custo do projeto com sua duração 

É a relação mais importante entre dois fatores do projeto. Observa-se, no gráfico anterior, que, em 
projetos realizados em um prazo reduzido, o custo do projeto torna-se elevado devido à quantidade 
de horas-extras, pessoal e controle. Quando o tempo destinado ao projeto é adequado, ele atinge seu 
ponto mais baixo (custo ótimo). Após esse período, o custo volta a subir devido à ineficiência no 
projeto e à perda de produtividade. 

Por exemplo, se uma pessoa constrói uma casa de alvenaria em dois meses, o custo do projeto será 
elevado devido à grande quantidade de pessoas trabalhando, muitas delas em regime de horas-extras, 
e devido à grande necessidade de controle, tornando os custos de administração significativamente 
mais altos. Se a pessoa dispõe de dez a doze meses para a construção, encontrará um valor mínimo 
de custo (ideal). Porém, se demorar vários anos para construir a casa, seu custo voltará a aumentar 
devido a perdas de material estocado e retrabalho (ineficiência). 








l.lOAnálise do Desempenho x Duração do Projeto 


Elevada 



Figura 4.5-Evolução do desempenho com a duração do projeto 

Observa-se, no gráfico anterior, que, em projetos com a duração muito reduzida, o desempenho 
(escopo e qualidade) pode ficar prejudicado pela pressa na conclusão. Já em projetos com uma 
duração ideal, o desempenho é máximo (ponto ótimo). Após esse ponto, a qualidade do projeto se 
estabiliza e pode até cair devido à ineficiência do projeto e à perda de motivação e senso de equipe. 

Por exemplo, é impossível construir uma casa de alvenaria de qualidade em dois dias. Se o 
construtor dispõe de dez a doze meses para a construção, encontrar-se-á o ponto ideal de qualidade. 
Porém, se o construtor levar 50 anos para construir uma casa relativamente simples, isso resultará em 
perda de qualidade por ineficiência, uma vez que a estrutura da casa, a alvenaria e os outros 
componentes estarão expostos às intempéries e à destruição durante todo o período do projeto e, 
muito provavelmente, o time do projeto deverá ter sido modificado inúmeras vezes nesses 50 anos. 



l.HAnálise do Desempenho x Investimento 



Figura 4.6-Evolução do desempenho com o investimento no projeto 

Observa-se, no gráfico anterior, que o desempenho do projeto é diretamente relacionado ao 
investimento nele. No entanto, ao se atingir um determinado nível de investimento, torna-se 
impossível converter mais capital em desempenho devido à presença de outros elementos limitantes 
do projeto, como tempo (prazo), riscos e escopo. 

Por exemplo, quanto mais capital se utiliza para construir uma casa, maior qualidade ela irá ter, pois 
utilizará materiais superiores e mão de obra mais qualificada. Porém, após um determinado patamar 
de investimento, o desempenho se estabiliza porque os limitantes do desempenho passam a ser 
outros, tais como o escopo e o tempo. 

As conclusões anteriores são genéricas e, devido à ineficiência gerencial ou técnica do projeto, 
pode-se ter uma casa que consuma um investimento elevado e não tenha a qualidade desejada. 



1.12Análise do Desempenho x Escopo 


Elevada 



Figura 4.7-Evolução do desempenho com o escopo do projeto 

Apesar de o escopo ser um dado definido pelo projeto, na maioria das vezes, é importante analisar o 
impacto de escopos genéricos e limitados no desempenho do projeto. Um escopo genérico demais 
não fornece sequer referenciais para a medição de desempenho. Já um escopo extremamente reduzido 
e específico torna o projeto quase inviável, pois as limitações e as restrições são tantas que o 
desempenho fica diretamente prejudicado. 

Por exemplo, se uma pessoa deseja comprar uma casa pronta e estabelece como escopo para sua 
procura uma casa que tenha cinco quartos, dois andares com varandas pintadas de verde, quatro 
vagas de garagem isoladas ao ar livre, pinheiros amarelos plantados no jardim, fonte luminosa na 
varanda principal, janelas de vidro na sala de jantar, cozinha com granito amarelo e bancada em 
mármore violeta, ela provavelmente não encontrará nenhuma casa exatamente nessas condições, 
tornando a possibilidade de se atingir o desempenho desejado pequena. Se ela procurar por uma casa 
de três quartos e duas vagas de garagem e um jardim florido, terá aumentado significativamente a 
possibilidade de encontrar algumas casas que atendam a esse escopo. Já se ela procurar por apenas 
uma casa (escopo muito genérico), possivelmente várias casas serão encontradas, mas a 
possibilidade de nenhuma casa agradar é muito grande. Quando se tem um escopo genérico demais, o 
processo de escolha se torna demorado devido à grande quantidade de opções (desempenho 
reduzido). 



QUESTÕES PARA REVISÃO 


1. Por que o final de um projeto normalmente tem um perfil lento de velocidade? 

2. Explique a diferença entre Oportunidade Construtiva e Intervenção Destrutiva. 

3. Por que o Monitoramento e o Controle devem acontecer ao longo de todo o projeto? 

4. Explique o conceito de que cada fase ou grupo de processo pode ser considerado um projeto. 

5. Por que não é possível a determinação direta do desempenho, do custo e do tempo do projeto 
de modo simultâneo? 

6. Como a importância relativa entre o desempenho, o custo e o tempo para um determinado 
projeto pode influenciar a estratégia de abordagem do projeto? 

7. Por que projetos coma duração excessiva acabam tendo seu custo aumentado? 

8. É correto afirmar que quanto mais capital disponível, mais desempenho é obtido? Justifique. 

9. Explique a relação entre escopo e desempenho. 



PALAVRA CRUZADA 


Ciclo de Vida de um Projeto 




V erticais 

1. Ponto máximo de 
esforço no projeto 

2. E o res ultado de um 
detalhamento 
excess ivo do escopo 

4, Fator determinado a 
partir da relação 
entre escopo e 
qualidade 

5. Fase que materializa 
tudo aquilo que foi 
planejado 
anterkxmente 

B. Prejudica a 

perWmance de um 
projeto 

7. Forma fálica da 
inter-relacâo erfre P, 
CeT 
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- PARTE III -PRINCIPAIS AREAS DO 
GERENCIAMENTO DE PROJETOS SEGUNDO O 

PMBOK GUIDE® 4 a Edição 



1. DEFINIÇÕES 


As áreas do gerenciamento de projetos descrevem o gerenciamento de projetos em termos de seus 
processos componentes. Esses processos podem ser organizados em nove grupos integrados, como 
descrito na figura a seguir. 



Figura 1.1 - Processo integrado de gerenciamento de projetos com destaque para as nove áreas de conhecimento 

Cada um desses processos tem um detalhamento específico e uma abrangência própria, porém está 
integrado, a todo o momento, cornos demais, formando um todo único e organizado. 

Gerenciamento da Integração - Área que engloba os processos requeridos para assegurar que 
todos os elementos do projeto sejam adequadamente coordenados e integrados, garantindo que o seu 
todo seja sempre beneficiado. 

r 

Gerenciamento de Escopo - Area que engloba os processos necessários para assegurar que, no 
projeto, esteja incluído todo o trabalho requerido, e somente o trabalho requerido, para concluí-lo de 
maneira bem sucedida. 

Gerenciamento de Tempo - Área que engloba os processos necessários para assegurar a conclusão 
do projeto no prazo previsto. É uma das áreas mais visíveis do gerenciamento de projetos. 

Gerenciamento de Custos - Área que engloba os processos requeridos para assegurar que um 
projeto seja concluído de acordo com seu orçamento previsto. 

Gerenciamento da Qualidade - Área que engloba os processos requeridos para assegurar que os 
produtos ou serviços do projeto estarão em conformidade com o solicitado pelo cliente, ou 
contratante. 

Gerenciamento de Recursos Humanos - Área que engloba os processos requeridos para fazer uso 
mais efetivo do pessoal envolvido como projeto. 






Gerenciamento das Comunicações - Área que engloba os processos requeridos para assegurar que 
as informações do projeto sejam adequadamente obtidas e disseminadas. 

Gerenciamento de Riscos - Área que visa planejar, identificar, qualificar, quantificar, responder e 
monitorar os riscos do projeto. 

Gerenciamento das Aquisições - Área que engloba os processos requeridos para adquirir bens e 
serviços de fora da organização promotora. Também conhecido como gerenciamento de suprimentos 
ou contratos. 



PROCESSOS DO PMBOK® GUIDE 4 a 
EDIÇÃO- 

No PMBOK® Guide 4 a Edição são abordados quarenta e dois processos divididos nas nove áreas 
de conhecimentos apresentadas anteriormente, formando um fluxo contínuo de processos, como o 
descrito na figura a seguir. 


INTEGRAÇÃO 

4.1 - Detenvofver o Termo 
de Abertura do Protelo 


■ INICIAÇÃO . 


K COMUNICAÇÕES V 
10.1 - Identificar as 
Partes Interessadas 


PLANEJAMENTO 


INTEGRAÇÃO 

44 - Desenvolver o Plano 
de Gerenciamento do 


1 f 


ESCOPO 

5.1 - Coletar os 
Requisitos 


ESCOPO 

5.2 - Defnr o Escopo 


ESCOPO 

54 • Criar a EAP 


f TEMPO \ 

6.1 - Definir as Atividades 


TEMPO 

6.2 - Sequenciar as 
Atividades 


f _ TEMPO \ 

6.3 • Eslimar os Recursos 
das Atividades 


f TEMPO A 

6 4 Estimar as Diraçüe.'. 
das Atividades 


TEMPO 

6.5- Desenvolver o 
Cronograma 


CUSTOS 

7.1 - Estimar os Custos 


CUSTOS 

7.2- Determinar o 
Orçamento 


f QUALIDADE > 

8.1 - Planejar a Qualidade 


/Decursos humanos\ 

9.1 - Desenvolver o Plano 
de Recursos Humanos 


COMUNICAÇÕES 

10.2 - Planejar as 
Comunicações 


RISCOS 

11.1 - Planejar o 
Gerenciamento dos 
Riscos 


RISCOS 

11.2 - Identificar os 
Riscos 


f RISCOS > 

11.3- Realizar a Análise 
Qualitativa dos Riscos 


f RISCOS 

11.4 - Realizar a Analise 
Quantltatrva dos Riscos 


RISCOS 

11.5-Planejar as 
Respostas aos Riscos 


AQUISIÇÕES 

12.1 - Planejar as 
Aquisições 


MONITORAMENTO E CONTROLE 


EXECUÇÃO 


INTEGRAÇÃO 

4.4 - Monitorar e 
Controlar o Trabalho do 


Kp 


INTEGRAÇÃO 

4.5 - Realizar o Controle 
Integrado de Mudanças 


\ t 


ESCOPO 

5.4 - Verificar o Escopo 


TEMPO 

6.6 - Controlar o 
Cronograma 


QUALIDADE > 

8.3 - Realizar o Controle 
da Qualidade 


RISCOS 

11.6 - Monitorar e 
Controlar os Riscos 


ESCOPO > 

5.5 - Controlar o Escopo 


í CUSTOS \ 

7.3 - Controlar os Custos 


COMUNICAÇÕES 

10,5 - Reportar o 
Desempenho 


AQUISIÇÕES 

12.3 - Administrar as 
Aquisições 


INTEGRAÇÃO 

4.3 - Orientar e Gerenciar 
a Execução do Projeto 


/1 

■! 


f QUALIDADE > 

8_2 - Realizar a Garantia 
da Qualidade 


V RECURSOS HUMANOS^ 

9.2 - Mobirzar a Equpe 
do Projeto 


DECURSOS HUMANOS^ 

94 - Desenvolver a 
Equipe do Projeto 


/£ecursoshumanos n 

9.4 - Gerenciar a Equipe 
do Profeto 


COMUNICAÇÕES 

10.3- Distribuiras 
Informações 


COMUNICAÇÕES 
10.4 - Gerenciar as 
Expectativas das Partes 
. Interessadas . 


AQUISIÇÕES 

124 - Conduzir as 
Aquisições 




ENCERRAMENTO 


INTEGRAÇÃO 

4.6 - Encerrar o Projeto 
ou Fase 


AQUISIÇÕES 

12.4 - Encerrar as 
Aquisições 


Figura 2.1 - Quarenta e dois processos do PMBOK Guide 4 a Edição subdivididos nas fases do projeto 

Observa-se na figura anterior que os processos dentro das nove áreas de conhecimento são inter- 
relacionados. A questão é que o PMBOK Guide 4 a Edição é estruturado de acordo com as áreas de 
conhecimento e não com os grupos de processos ou fases do projeto. O Anexo I apresenta o original 
do artigo apresentado ao PMI em 2001 que propõe uma nova visão do PMBOK Guide orientada para 

as fases do projeto 2 . 




















































































































































2. DESMEMBRANDO O PMBOK 
ATRAVÉS DE MAPAS MENTAIS 
{MINDMAPS) 


Mapas mentais, também conhecidos como Mindmaps são considerados um padrão mundial para 
criação, gerenciamento e comunicação de ideias. Os mapas mentais apoiam a organização de ideias, 
de conhecimento através de uma visualização intuitiva e amigável, alem de possuir grande 
versatilidade visual. 

Mapas mentais se iniciam com uma ideia central, onde todos os ramos do mapa significam uma 
decomposição da ideia principal em ideias relacionadas, baseadas em um modelo visual de 
pensamento. 

O pensamento visual é um conceito baseado nas pesquisas de como o cérebro humano funcional, 
onde se busca o estímulo do senso visual e tátil, de modo a aumentar a criatividade e o entendimento 
das partes em um todo unificado, reduzindo o tempo de desenvolvimento e entendimento de ideias. 

Como se sabe, o PMBOK Guide é dividido em nove áreas e quarenta e dois processos, como é 
apresentado nos mapas mentais a seguir. Em cada um dos próximos capítulos, os mapas mentais de 
cada uma das áreas serão apresentados em detalhes. 
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Figura 3.1 - Mapa mental das nove áreas do gerenciamento de projetos segundo o PMBOK Guide 4 a Edição” 

Neste mapa mental as nove áreas de conhecimento do PMBOK Guide são apresentadas dentro do 
todo de conhecimento do PMI. 

Ao detalhar cada uma das áreas nos quarenta e dois processos, tem-se o mapa a seguir, onde os 
processos são agrupados de acordo comas cinco fases ou grupos de processo. 
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Figura 3.2 - Mapa mental dos quarenta e dois processos do PMBOK Guide 4 a Edição. 








3. GERENCIAMENTO DA 
INTEGRAÇÃO 




O sucesso de todo o gerenciamento de projetos depende unicamente da relação entre suas áreas. ” 



1.13Defínição 


O processo de integração do projeto consiste em garantir que todas as demais áreas estejam 
integradas em um todo único. Seu objetivo é estruturar todo o projeto de modo a garantir que as 
necessidades dos envolvidos sejam atendidas pelo projeto. 



Figura 4.1-Gerenciamento da Integração como área central do gerenciamento de projetos 



1.14 Mindmap dos processos de Gerenciamento da Integração 

Os processos de gerenciamento da integração se decompõem conforme o mapa mental a seguir. 
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Figura 4.2 - Mapa mental do Gerenciamento da Integração 








1.15Processos de Gerenciamento da Integração 


O PMBOK subdivide o gerenciamento da integração em seis processos: 

• Desenvolver o termo de abertura do projeto (4.1) ; 

• Desenvolver o plano de gerenciamento do projeto (4.2) ; 

• Orientar e gerenciar a execução do projeto (4.3) ; 

• Monitorar e controlar o trabalho do projeto (4.4); 

• Realizar o controle integrado de mudanças (4.5) ; 

• Encerrar o projeto ou fase (4.6). 


Iniciacao 


4.1 - Desenvutaer o 
termo rte abertura do 
projeto 


GERENCIAMENTO DA INTEGRAÇÃO 
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4 5 - Retal irar o 
ccrr role ntegrado de 
mudanças 


Encerramento 


4 6 - Encerrar o 
projeto ou fase 


Figura 4.3 - Processos de Gerenciamento da Integração distribuídos ao longo das fases do projeto 

Desenvolver o termo de abertura do projeto - Desenvolver o termo de abertura do projeto é o 
processo de desenvolvimento de um documento que formalmente autoriza um projeto ou uma fase e a 
documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes 
interessadas. Estabelece uma parceria entre a organização executora e a organização solicitante (ou 
cliente, no caso de projetos externos). 


■ IIHIl ■ 
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Figura 4.4 - Mapa mental do processo Desenvolver o termo de abertura do projeto 

Desenvolver o plano de gerenciamento do projeto - Desenvolver o plano de gerenciamento do 
projeto é o processo de documentação das ações necessárias para definir, preparar, integrar e 
coordenar todos os planos auxiliares. 
















Figura 4.5 - Mapa mental do processo Desenvolver o plano de gerenciamento do projeto 

Orientar e gerenciar a execução do projeto - Orientar e gerenciar a execução do projeto é o 
processo de realização do trabalho definido no plano de gerenciamento do projeto para atingir os 
objetivos. 






Figura 4.6- Mapa mental do processo Orientar e gerenciar a execução do projeto 

Monitorar e controlar o trabalho do projeto - Monitorar e controlar o trabalho do projeto é o 
processo de acompanhamento, revisão e ajuste do progresso para atender aos objetivos de 
desempenho definidos no plano de gerenciamento. 


Figura 4.7-Mapa mental do processo Monitorar e controlar o trabalho do projeto 

Realizar o controle integrado de mudanças - Realizar o controle integrado de mudanças é o 
processo de revisão de todas as solicitações, aprovação e gerenciamento de mudanças em entregas, 
ativos de processos organizacionais, documentos de projeto e plano de gerenciamento do projeto. 




Figura 4.8-Mapa mental do processo Realizar o controle integrado de mudanças 

















Encerrar o projeto ou fase - Encerrar o projeto ou fase é o processo de finalização de todas as 
atividades, de todos os grupos de processos de gerenciamento do projeto, para encerrar formalmente 
o projeto ou a fase. 





Figura 4.9-Mapa mental do processo Encerrar o projeto ou fase 

No gerenciamento da integração, é importante que se atente para os seguintes aspectos: 

• Verificar se todas as outras áreas têm processos de controle de mudanças específicos que 
atuam como subsídio ao processo global de controle de mudanças; 

• manter sempre os registros de desempenho para garantir um melhor monitoramento do 
desempenho; 

• avaliar sempre se as metas e os objetivos do projeto estão evidenciados em todos os outros 
planos do projeto; 

• avaliar sempre de maneira integrada qualquer necessidade de replanejamento; 

• utilizar-se do plano de gerenciamento das comunicações para garantir que todas as 
informações relativas à integração estejam disponíveis para as demais áreas. 





l.lóTermo de Abertura do Projeto ou Project Charter 


O Termo de Abertura do Projeto ou Project Charter é o documento legal que reconhece a existência 
de um projeto. Ele serve como uma linha de base para o trabalho do gerente do projeto. Contém 
diversas informações sobre o projeto, incluindo estimativas iniciais de qual o prazo destinado, 
recursos necessários e orçamento disponível. 

Usualmente o termo de abertura do projeto contém 

• título do projeto; 

• um resumo das condições que definem o projeto (introdução); 

• justificativa do projeto; 

• nome do gerente de projeto e suas responsabilidades e autoridades; 

• necessidades básicas do trabalho a ser realizado; 

• principais partes interessadas; 

• descrição do produto do projeto; 

• cronograma básico do projeto; 

• estimativas iniciais de custo; 

• necessidades iniciais de recursos; 

• necessidade de suporte pela organização; 

• premissas e restrições; 

• controle e gerenciamento das informações do projeto; 

• aprovações com assinatura do executivo responsável pelo documento (elemento externo ao 

projeto). 



1.17Plano Global do Projeto 


O Plano Global do Projeto é o documento formal que descreve os procedimentos a serem conduzidos 

r 

durante a sua execução. E o alicerce de toda a execução. Nele estão contidos todos os planos 
secundários, cronogramas, aspectos técnicos, etc. 

O Plano Global do Projeto deve conter: 

• a visão geral dos objetivos, metas e escopo do projeto de uma maneira resumida e macro para 
atender aos altos executivos do projeto (pequena introdução do assunto); 

• o objetivo detalhado do projeto para atender ao gerente do projeto e ao time do projeto; 

• o nome e as responsabilidades do gerente e do time principal do projeto (matriz de 
responsabilidades); 

• o organograma do projeto; 

• estudo técnico da solução a ser adotada pelo projeto; 

• aspectos contratuais quanto à participação de elementos externos ao projeto; 

• Estrutura Analítica do Projeto ou Work Breakdown Structure (WBS); 

• cronogramas (Gráficos de Gantt e Diagramas de Rede); 

• principais marcos com suas datas; 

• utilização de recursos pelo projeto (relatório comas funções); 

• orçamento, análise de custos e fluxos de caixa; 

• necessidade de contratação e treinamento de pessoal; 

• formas previstas de avaliação dos índices de qualidade e desempenho a serem atingidos pelo 
projeto; 

• potenciais obstáculos a serem enfrentados pelo projeto e possíveis soluções; 

• lista de pendências; 

• planos das áreas de conhecimento (também considerados planos auxiliares)-; 

• Plano de Gerenciamento de Escopo; 

• Plano de Gerenciamento de Tempo; 

• Plano de Gerenciamento de Custos; 

• Plano de Gerenciamento da Qualidade; 

• Plano de Gerenciamento de Recursos Humanos; 

• Plano de Gerenciamento das Comunicações; 

• Plano de Gerenciamento de Riscos; 

• Plano de Gerenciamento das Aquisições. 


GERENCIAMENTO DE ESCOPO 


(6 

Aqueles que se esquecem dos erros do passado estão condenados a repeti-los no futuro. ” 


George Santayana 



1.18Defínição 


O gerenciamento de escopo tem como objetivo principal definir e controlar os trabalhos a serem 
realizados pelo projeto de modo a garantir que o produto, ou serviço, desejado seja obtido através 
da menor quantidade de trabalho possível, sem abandonar nenhuma premissa estabelecida no 
objetivo do projeto. 

Uma importante diferenciação precisa ser estabelecida entre projeto e produto, no que diz respeito 
ao escopo. Kerzner afirma que a maior parte dos ciclos de vida de produtos e projetos são similares, 
exceto em um fator: os projetos têm um ciclo de vida predefinido, ao passo que o produto existe 
enquanto existir uma finalidade comercial para ele, ou seja, enquanto ele for lucrativo e interessante 
para a organização. 

Portanto, o escopo de um projeto é definido como o trabalho que precisa ser desenvolvido para 
garantir a entrega de um determinado produto dentro de todas as suas especificações e funções. 
Genericamente, o escopo pode ser subdividido em: 

Escopo Funcional - Conjunto de características funcionais do produto, ou serviço, a ser 
desenvolvido pelo projeto, tais como capacidade, mercado, filosofia, etc. Normalmente são 
direcionados ao cliente e são também denominados requisitos funcionais; 

Escopo Técnico - Características técnicas do projeto, destacando os padrões e as especificações a 
serem utilizadas, normas legais a serem obedecidas, procedimentos de qualidade (ISO) etc. 
Normalmente são direcionados para a equipe do projeto e são também denominados requisitos 
técnicos; 

Escopo de Atividades - Trabalho a ser realizado para prover o escopo técnico e o escopo funcional 
do produto, ou serviços, do projeto, normalmente evidenciado na Estrutura Analítica do Projeto 
(EAP). 

Um projeto com um detalhamento de escopo significativamente grande possui uma complexidade 
muito alta no que diz respeito ao gerenciamento de escopo. É importante trabalhar-se com um escopo 
que garanta o produto, ou serviço, do projeto, sem ser demasiadamente detalhado, para que seu 
gerenciamento não se torne excessivamente complexo. 



Figura 5.1 - Detalhamento do Escopo x Complexidade no gerenciamento 

























1.19 Mindmap dos Processos de Gerenciamento de Escopo 

Os processos de gerenciamento de escopo se decompõem conforme o mapa mental a seguir. 
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Figura 5.2 - Mapa mental do Gerenciamento de Escopo 
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1.20Processos de Gerenciamento de Escopo 


O PMBOK subdivide o gerenciamento de escopo em cinco processos, a saber: 


• Coletar os requisitos (5.1); 

• Definir o escopo (5.2); 

• Criar a EAP (5.3); 

• Verificar o escopo (5.4); 

• Controlar o escopo (5.5). 


GERENCIAMENTO DO ESCOPO 


Inlclacao Planelamento Execução Controle tncerramento 


5.1 -Cotaaroa 
requsros 


5.2 * Deflrtr o «copo 


53-CnaraEAP 


54 - Vecfflcar o 
escapo 


5.5 - Corr.roldí o 
escapo 


Figura 5.3 - Processos de Gerenciamento de Escopo distribuídos ao longo das fases do projeto 

Coletar os requisitos - Processo de definir e documentar as funções e funcionalidades do projeto e 
do produto necessárias para atender às necessidades e expectativas das partes interessadas. 







Figura 5.4 - Mapa mental do processo Coletar os requisitos 

Definir o escopo - Definir o escopo é processo de desenvolvimento de uma descrição detalhada do 
projeto e do produto. A preparação detalhada da declaração do escopo é crítica para o sucesso e 
baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação 
do projeto. 





















Figura 5.5 - Mapa mental do processo Definir o escopo 

Criar a EAP - Criar a EAP é o processo de subdivisão das entregas e do trabalho do projeto em 
componentes menores e de gerenciamento mais fácil. 



Figura 5.6 - Mapa mental do processo Criar a EAP 

Verificar o escopo - Verificar o escopo é o processo de formalização da aceitação das entregas 
concluídas do projeto. Inclui a revisão das entregas como cliente ou patrocinador para assegurar que 
foram concluídas satisfatoriamente e obter deles a aceitação formal das mesmas. 



Figura 5.7 - Mapa mental do processo Verificar o escopo 

Controlar o escopo - É o processo de monitoramento do andamento do escopo do projeto e do 
produto e gerenciamento das mudanças feitas na linha de base do escopo. 




Figura 5.8 - Mapa mental do processo Controlar o escopo 





1.21Documento de Requisitos do Projeto 


É o documento que registra os requisitos necessários para atender às necessidades do projeto. Ele 
pode ser construído a partir de requisitos de alto nível, sendo detalhado progressivamente com o 
projeto. 

Normalmente o Documento de Requisitos do Projeto contém: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descrição básica do projeto e da oportunidade; 

• objetivo do projeto; 

• requisitos funcionais desejáveis (priorizados); 

• requisitos não funcionais (relacionados ao desempenho, segurança, confidencialidade etc.); 

• requerimentos principais de qualidade (serão detalhados no Plano de Qualidade); 

• critérios de aceitação do projeto; 

• potenciais impactos do projeto em outras áreas; 

• restrições consideradas na criação dos requerimentos; 

• premissas consideradas na criação dos requerimentos; 

• registro de alterações no documento de requisitos; 

• aprovações. 



1.22Plano de Gerenciamento dos Requisitos do Projeto 


O Plano de Gerenciamento dos Requisitos do Projeto é auxiliar ao plano de gerenciamento de 
projetos e descreve os procedimentos que serão utilizados para documentar como os requerimentos 
serão analisados, documentados e gerenciados através do projeto. 

No plano, deve estar documentado: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• critério de priorização dos requisitos; 

• critérios de rastreabilidade dos requisitos; 

• sistema de controle de mudanças nos requisitos; 

• níveis de aprovação de mudanças nos requisitos; 

• outros assuntos relacionados ao gerenciamento de requisitos do projeto não previstos no 
plano; 

• registro de alterações no documento; 

• aprovações. 



1.23Matriz de Rastreabilidade de Requisitos (RTM) 


A matriz de rastreabilidade de requisitos ou Requirements Traceability Matrix (RTM) é um 
documento em forma de tabela que lista os requisitos do projeto de modo a permitir o rastreamento 
do requisito dentro da EAP do projeto, determinando seu status, teste e requisitos relacionados. Tem 
como objetivo garantir que cada requerimento adicione valor ao objetivo do projeto e esteja 
perfeitamente ligado ao escopo de atividades. 

A matriz usualmente contém os seguintes campos: 

• ID do requisito; 

• nome do requisito; 

• descrição do requisito; 

• tipo do requisito; 

• prioridade do requisito; 

• elemento(s) da EAP onde o requisito está associado; 

• outros requisitos associados e relacionados (ID); 

• status do requisito; 

• critério de aceitação e conclusão; 

• comentários. 



1.24Declaração de Escopo ou Scope Statement 


É o documento que formaliza o escopo de todos os trabalhos a serem desenvolvidos no projeto, 
servindo de base para futuras decisões do projeto. É possível que, ao longo do projeto, a declaração 
de escopo seja revisada, ou refinada, para refletir as mudanças acontecidas nele. 

Normalmente, a Declaração de Escopo contém: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• nome do patrocinador; 

• nome do gerente do projeto e suas responsabilidades e autoridades; 

• nome dos integrantes do time do projeto; 

• descrição do projeto; 

• objetivo do projeto; 

• justificativa do projeto; 

• produto do projeto; 

• expectativa do cliente/patrocinador; 

• fatores de sucesso do projeto; 

• restrições; 

• premissas; 

• exclusões específicas (tudo o que não será abordado pelo projeto); 

• principais atividades e estratégias do projeto; 

• principais entregas do projeto; 

• orçamento básico do projeto; 

• plano de entregas e marcos do projeto; 

• registro de alterações no documento; 

• aprovações. 



1.25Plano de Gerenciamento do Escopo 


O Plano de Gerenciamento do Escopo é auxiliar ao plano de gerenciamento de projetos e descreve 
os procedimentos que serão utilizados para gerenciar todo o escopo do projeto. 

No plano, deve estar documentado: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento do escopo (regras gerais); 

• priorização das mudanças de escopo e respostas; 

• sistema de controle de mudanças de escopo ( Scope Change Control System ); 

• frequência de avaliação do escopo do projeto; 

• alocação financeira das mudanças de escopo; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento do escopo; 

• outros assuntos relacionados ao gerenciamento do escopo do projeto não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DE TEMPO 


Quando eles dizem que você está atrasado no projeto, isso é somente uma maneira educada de se dizer que você tem um péssimo senso de prazos. ” 


George McGovern 



1.26Definição 


O gerenciamento do tempo, juntamente com o gerenciamento de custos, são as mais visíveis áreas do 
gerenciamento de projeto. A grande maioria das pessoas que se interessam por projetos têm como 
objetivo inicial controlar prazos, confeccionar cronogramas e redes, etc. 

O principal objetivo dessa área é garantir que o projeto seja concluído dentro do prazo determinado. 

Como já se sabe, o tempo não espera por ninguém, especialmente por aquele gerente que constrói 
cronogramas baseados em datas impossíveis. O cronograma do projeto é sempre uma restrição, até 
mesmo quando a data de término não é crítica. Se um projeto atrasa, na maioria das vezes ele irá 
consumir um capital que ele não tinha previsto, comprometendo, também, o seu custo, podendo até 
mesmo causar sérias consequências mercadológicas para o produto, ou serviço, do projeto. 

O gerenciamento do tempo também é considerado uma das razões mais importantes para o 
estabelecimento de conflitos entre os envolvidos no projeto, conforme estudo realizado por 
Thamhain & Wilemon (1975) e revisto por Posner (1986). 



Figura 6.1 - Tendência de conflitos relativos ao gerenciamento do tempo ao longo do projeto (baseado em trabalhos de Thamhain 
e Wilemon) 







1.27 Mindmap dos Processos de Gerenciamento de Tempo 

Os processos de gerenciamento de tempo se decompõem conforme o mapa mental a seguir. 




Figura 6.2 - Mapa mental do Gerenciamento de Tempo 





1.28Processos de Gerenciamento de Tempo 


O PMBOK subdivide o gerenciamento de tempo em seis processos: 

• Definir as atividades (6.1); 

• Sequenciar as atividades (6.2); 

• Estimar os recursos das atividades (6.3); 

• Estimar as durações das atividades (6.4); 

• Desenvolver o cronograma (6.5); 

• Controlar o 


Figura 6.3 - Processos de Gerenciamento de Tempo distribuídos ao longo das fases do projeto 

Definir as atividades - Definir as atividades é o processo de identificação das ações específicas a 
serem realizadas para produzir as entregas do projeto 


cronograma (6.6); 
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Figura 6.4 - Mapa mental do processo Definir as atividades 

Sequenciar as atividades - Sequenciar as atividades é o processo de identificação e documentação 
dos relacionamentos entre as atividades do projeto. 










Figura 6.5 - Mapa mental do processo Sequenciar as atividades 


Estimar os recursos das atividades - Estimar os recursos da atividade é o processo de estimativa 
dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que serão necessários 
para realizar cada atividade. 


Figura 6.6 - Mapa mental do processo Estimar os recursos das atividades 

Estimar as durações das atividades - Estimar as durações da atividade é o processo de estimativa 
do número de períodos de trabalho que serão necessários para terminar as atividades específicas 
cornos recursos estimados. 





Figura 6.7 - Mapa mental do processo Estimar as durações das atividades 

Desenvolver o cronograma - Desenvolver o cronograma é o processo de análise de sequências das 
atividades, suas durações, recursos necessários e restrições do cronograma visando criar o 
cronograma do projeto. 
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Figura 6.8 - Mapa mental do processo Desenvolver o cronograma 

Controlar o cronograma - Controlar o cronograma é o processo de monitoramento do andamento do 
projeto para atualização do seu progresso e gerenciamento das mudanças feitas na linha de base do 
cronograma. 





Figura 6.9 - Mapa mental do processo Controlar o cronograma 

No gerenciamento de tempo, é importante que se atente para os seguintes aspectos: 

• ne nhu m cronograma é perfeito, mas isso não impede que o projeto faça sempre a melhor 
estimativa possível; 

• o cronograma do projeto determina, em parte, o seu orçamento; 

• o nível de detalhamento dos cronogramas é uma função do tamanho do projeto; 

• sempre deve-se estimar o tempo baseado no melhor e no pior cenário; 

• gerenciamento de projetos não é somente gerenciamento de tempo. 








1.29Plano de Gerenciamento do Cronograma 


Como já citado anteriormente no capítulo de integração e escopo, o plano de gerenciamento do 

cronograma também é considerado um documento de apoio do projeto 1 . O plano formaliza os 
procedimentos que serão utilizados para gerenciar todos os prazos do projeto. 

No plano, deve estar documentado: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento do cronograma (regras gerais); 

• priorização das mudanças de prazos; 

• sistema de controle de mudanças de prazos ( Time Change Control System ); 

• frequência de avaliação de prazos do projeto; 

• alocação financeira para o gerenciamento do cronograma; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento do cronograma; 

• outros assuntos relacionados ao gerenciamento de tempo não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 


GERENCIAMENTO DE CUSTOS 


Nunca se esqueça: uma pequena mentira destrói completamente toda a integridade e a reputação do projeto. ” 


Baseado em Baltazar Garcián 



UODefínição 


O gerenciamento de custos tem como objetivo garantir que o capital disponível será suficiente para 
obter todos os recursos para se realizaremos trabalhos do projeto. 

O gerenciamento de custos não pode considerar apenas os custos incorridos no próprio projeto. 
Muitas vezes, o projeto está desenvolvendo um produto, ou serviço, com interesse comercial, e esse 
produto, por sua vez, estará recompensando financeiramente a empresa, retornando tanto o dinheiro 
investido quanto o lucro desejado, estabelecido na concepção do projeto. 



Figura 7.1 - Ciclo financeiro de vida de um projeto 

No gráfico anterior, tem-se, em um primeiro momento, o ciclo de investimentos no projeto. O custo 
total do projeto é de $x, e seu prazo de desenvolvimento é de y meses. Após esse período, inicia-se, 
imediatamente, a comercialização, obtendo uma receita conforme a curva superior do gráfico e um 
lucro operacional dado pela segunda curva dos retornos acumulados. Quando o lucro operacional 
acumulado atinge $x, tem-se o Breakeven do projeto, ou seja, o tempo que o projeto leva para se 
pagar, que é dado por z meses a partir do início do projeto, ou z-y meses a partir do início da 
comercialização do produto. Após esse período, o projeto passa a ter um lucro real, determinado 
pelo valor do lucro operacional que superar $x. Porém, o produto desenvolvido também tem um 
ciclo de vida comercial, e, após um tempo t, o produto se deteriora comercialmente, tendo alcançado 
uma receita operacional final de $k, um lucro operacional total de $w e um lucro final do 
empreendimento (resultado) de $(w-x). 

Outro aspecto importante com relação ao gerenciamento de custos diz respeito aos orçamentos. O 
orçamento não pode ser considerado simplesmente como uma visão do plano. Ele é um mecanismo 
poderoso de controle. O orçamento serve como parâmetro de comparação, uma linha de base da qual 
se extraem informações sobre o desempenho financeiro do projeto. O orçamento precisa ser validado 
ao longo do tempo, durante a execução do projeto (controle de custos), para que os eventuais 
problemas sejam identificados o mais cedo possível para que a solução possa ser antecipada, 
evitando-se, assim, danos mais graves ao orçamento. 















Muitas vezes, o gerenciamento de custos propicia um processo de recompensa para os envolvidos no 
projeto, através de participação nos seus resultados. Nesses casos, o controle de custos merece uma 
atenção especial, sendo talvez alvo de um processo de orçamentação paralelo, de modo a garantir 
que eles reflitam o real resultado do projeto. 

As maiores causas de falhas no gerenciamento de custos podem ser atribuídas a elementos externos 
ao processo isolado de custos. São elas: 

• interpretação errada do trabalho a ser realizado; 

• omissão na definição do escopo do trabalho; 

• cronograma pobremente definido ou excessivamente otimista; 

• fracasso na avaliação de riscos; 

• estrutura analítica do projeto (WBS) mal definida; 

• parâmetros de qualidade mal estabelecidos; 

• fracasso na estimativa dos custos indiretos e administrativos do projeto. 



1.31 Mindmap dos Processos de Gerenciamento de Custos 

Os processos de gerenciamento de custos se decompõem conforme o mapa mental a seguir. 
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Figura 7.2 - Mapa mental do Gerenciamento de Custos 



1.32Processos de Gerenciamento de Custos 


O PMBOK subdivide o gerenciamento de custos em três processos: 

• Estimar os custos (7.1); 

• Determinar o orçamento (7.2); 

• Controlar os custos (7.3). 
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Figura 7.3 - Processos de Gerenciamento de Custos distribuídos ao longo das fases do projeto 

Estimar os custos - Estimar os custos é o processo de desenvolvimento de uma estimativa dos 
recursos monetários necessários para executar as atividades do projeto. 
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Figura 7.4 - Mapa mental do processo Estimar os custos 

Determinar o orçamento - Determinar o orçamento é o processo de agregação dos custos estimados 
de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos 
autorizada. 




















Figura 7.5 - Mapa mental do processo Determinar o orçamento 


Controlar os custos - Controlar os custos é o processo de monitoramento do progresso do projeto 
para atualização do seu orçamento e gerenciamento das mudanças feitas na linha de base dos custos. 



Figura 7.6 - Mapa mental do processo Controlar os custos 

No gerenciamento de custos, é importante que se atente para os seguintes fatores: 

• Em projetos sob contrato, é importante diferenciar estimativas de custos de precificação: 
custos são resultantes das necessidades de recursos, etc., do projeto, enquanto o preço é uma 
decisão de estratégia de negócio da organização; 

• qualquer estimativa de custos deve vir acompanhada por sua memória de cálculo; 

• bancos de dados comerciais sempre podem ser utilizados na estimativa de recursos e custos, 
bem como os registros obtidos em projetos anteriores; 

• muitas empresas patrocinam seus projetos, mesmo com os custos não sendo recuperados, 
porque têm interesse em atingir uma meta de longo prazo para a organização. 




1.33Plano de Gerenciamento de Custos 


O Plano de Gerenciamento de Custos é auxiliar ao plano de projeto que descreve os procedimentos 
que serão utilizados para gerenciar todos os custos do projeto. 

No plano, deve estar documentado: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento de custos (regras gerais); 

• descrição das reservas gerenciais e da autonomia em sua utilização; 

• sistema de controle de mudanças de prazos ( Time Change Control System ); 

• frequência de avaliação do orçamento do projeto e das reservas gerenciais; 

• alocação financeira das mudanças no orçamento; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento de custos; 

• outros assuntos relacionados ao gerenciamento de custos não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DA QUALIDADE 




O conceito moderno de qualidade tem foco na satisfação do cliente e na conformidade do projeto com as necessidades desse cliente, e não com padrões previamente criados pela empresa ou pelo time do projeto. ’ 


Lewis R. Ireland 



1.34Defínição 


O objetivo mais importante desta área é garantir que o projeto será concluído dentro da qualidade 
desejada, garantindo a satisfação das necessidades de todos os envolvidos. O gerente do projeto é o 
principal responsável pelo gerenciamento da qualidade no projeto, devendo dar igual prioridade 
para o gerenciamento da qualidade, dos custos e do tempo. 

Os conceitos de qualidade têm recebido uma atenção diferenciada no gerenciamento de projetos nos 
últimos anos. A necessidade de melhorias na qualidade foi impulsionada por vários fatores, dentre 
eles: 

• exigência de alto desempenho; 

• ciclo de vida de desenvolvimento de produtos reduzido; 

• níveis tecnológicos elevados; 

• processos e equipamentos levados constantemente a condições limítrofes. 

A qualidade envolve inúmeras dimensões. Dentre elas podem ser caracterizadas as seguintes: 

Defeito zero - Não existe tolerância a erros dentro do sistema. A meta é que, em todos os processos, 
não existam falhas e exista dentro do projeto um ambiente isento de defeitos. 

O cliente é o próximo elemento no processo - Conceito baseado na necessidade de 
desenvolvimento de um sistema que seja capaz de garantir que o produto ou serviço seja transferido 
para o cliente de maneira correta. 

Faça correto da primeira vez - É meta do gerenciamento da qualidade garantir que cada ação do 
projeto seja desenvolvida corretamente na primeira vez, porque seus custos são muito mais baratos 
assim. O processo de correção é várias vezes mais caro que o processo de planejamento. 

Melhoria contínua - Conceito que reconhece que o mundo está em constante mutação e que o 
processo satisfatório, hoje, pode não o ser amanhã, fazendo com que os mecanismos de controle do 
projeto necessitem de aprimoramentos constantes para garantir a qualidade do produto, ou serviço. 

Outro aspecto importante a ser discutido é o custo da qualidade. O custo da qualidade é definido 
como o investimento total para atingir a qualidade desejada do produto ou serviço. Isso inclui todo o 
trabalho necessário para construir um produto, ou serviço, que está em conformidade, bem como todo 
o custo resultante da não-conformidade. 


Custo da Conformidade 

Custo da Não-Conformidade 

• Planejamento; 

• Treinamento; 

• Controle de processos; 

• Testes; 

• Auditoria de qualidade; 

• Manutenção 

• Refugos; 

• Retrabalho; 

• Reparos na garantia; 

• Ações corretivas no produto; 

• Atrasos no cronograma 


Tabela 8.1 - Custos de conformidade x custos de não conformidade 

A maior parte das pessoas acredita que o custo e a qualidade são linearmente relacionados, ou seja, 
se o orçamento é ampliado em 10%, a qualidade também poderá ser melhorada em 10%. No gráfico 





a seguir tem-se a relação tempo, custo e a qualidade palpável. 



Figura 8.1 - Relação custo x qualidade palpável ao longo do tempo no projeto 

Observa-se que os primeiros 80% do orçamento conseguem evidenciar apenas 10% da qualidade. Os 
outros 20% restantes é que possibilitam os outros 90% da qualidade restantes, mostrando uma 
relação não-linear entre os fatores. 







1.35 Mindmap dos Processos de Gerenciamento da Qualidade 

Os processos de gerenciamento da qualidade se decompõem conforme o mapa mental a seguir. 



Figura 8.2 - Mapa mental do Gerenciamento da Qualidade 




1.36Processos de Gerenciamento da Qualidade 


O PMBOK subdivide o gerenciamento da qualidade em três processos: 

• Planejar a qualidade (8.1); 

• Realizar a garantia da qualidade (8.2); 

• Realizar o controle da qualidade (8.3). 
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Figura 8.3 - Processos de Gerenciamento da Qualidade distribuídos ao longo das fases do projeto 

Planejar a qualidade - Planejar a qualidade é o processo de identificação dos requisitos e/ou 
padrões de qualidade do projeto e do produto, além da documentação de como o projeto demonstrará 
a conformidade. 



Figura 8.4 - Mapa mental do processo Planejar a qualidade 

Realizar a garantia da qualidade - Realizar a garantia da qualidade é o processo de auditoria dos 
requisitos de qualidade e dos resultados das medições de controle da qualidade para garantir que 
sejam usados os padrões de qualidade e definições operacionais apropriados. 


Figura 8.5 - Mapa mental do processo Realizar a garantia da qualidade 

Realizar o controle da qualidade - Realizar o controle da qualidade é o processo de monitoramento 
e registro dos resultados da execução das atividades de qualidade para avaliar o desempenho e 
recomendar as mudanças necessárias. 
















Figura 8.4 - Mapa mental do processo Realizar o controle da qualidade 





1.37Plano de Gerenciamento da Qualidade 


O Plano de Gerenciamento da Qualidade é também um documento auxiliar do plano de 
gerenciamento de projetos que descreve os procedimentos que serão utilizados para gerenciar todos 
os aspectos da qualidade do projeto. 

No plano, deve estar documentado: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento da qualidade (regras gerais); 

• listagem dos requisitos de qualidade; 

• listagem dos padrões de qualidade associados; 

• priorização das mudanças nos requisitos de qualidade e respostas; 

• sistema de controle de mudanças da qualidade ( Quality Change Control System ); 

• frequência de avaliação dos requisitos de qualidade do projeto; 

• alocação financeira das mudanças nos requisitos de qualidade; 

• administração do plano de gerenciamento da qualidade; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento da qualidade; 

• outros assuntos relacionados ao gerenciamento da qualidade não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DE RECURSOS 
HUMANOS 


Esteja sempre alerta para as oportunidades de reconhecer as pessoas e de mostrar a elas que você elogia e aprecia o seu esforço. ” 


Vijay K Verma 



1.38Defínição 


O gerenciamento dos recursos humanos tem como objetivo central fazer o melhor uso dos indivíduos 
envolvidos no projeto. Como se sabe, as pessoas são o elo central dos projetos e seu recurso mais 
importante. Eles definem as metas, os planos, organizam o trabalho, produzem os resultados, 
direcionam, coordenam e controlam as atividades do projeto, utilizando suas habilidades técnicas e 
sociais. Todos os resultados do projeto podem ser vistos como fruto das relações humanas e das 
habilidades interpessoais dos envolvidos, uma vez que a satisfação pessoal e a qualidade de vida 
estão se tornando um dos fatores-chave da motivação de qualquer profissional. 

No passado, a maioria dos projetos se preocupou unicamente com aspectos técnicos, que foram 
altamente desenvolvidos. Porém, os aspectos humanos, que poderíam conduzir o projeto aos mesmos 
ganhos do desenvolvimento técnico, foram relegados a um segundo plano. Agora, são eles o foco dos 
principais estudos e trabalhos na área, de modo a compensar essa desproporcionalidade. 

O sucesso ou o fracasso do projeto dependem diretamente do gerenciamento dos recursos humanos. 
Conforme Galbraith, duas premissas asseguram essa afirmativa: 

• pessoas influenciam o sucesso ou o fracasso do projeto; 

• os problemas do projeto somente podem ser resolvidos por pessoas. 

Como os custos e o fluxo de caixa variam significativamente através do ciclo de vida do projeto, os 
recursos humanos são necessários em vários níveis de especialidade e experiência, dependendo da 
natureza do trabalho a ser realizado, do nível de maturidade do time do projeto e das restrições 
internas e externas. 



• Analítico» 

- Planejadores 

- Técnicos 

• Integradores 


• Comandante 

- Chefe 

- Gerentes 

- Controladores 


Ftoalizador 

Faciitador 

Instrutor 


Tipo 


Empreendedores 

Inovadores 

Criativos 


Tempo 


Figura 9.1 - Tipos de profissionais requeridos ao longo das fases do projeto 







1.39 Mindmap dos Processos de Gerenciamento de Recursos 
Humanos 

Os processos de gerenciamento de recursos humanos se decompõem conforme o mapa mental 
seguir. 
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Figura 9.2 - Mapa mental do Gerenciamento de Recursos Humanos 



1.40Processos de Gerenciamento de Recursos Humanos 


O PMBOK subdivide o gerenciamento de recursos humanos em quatro processos: 

• Desenvolver o plano de recursos humanos (9.1); 

• Mobilizar a equipe do projeto (9.2); 

• Desenvolver a equipe do projeto (9.3); 

• Gerenciar a equipe do projeto (9.4). 
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Figura 9.3 - Processos de Gerenciamento de Recursos Humanos distribuídos ao longo das fases do projeto 

Desenvolver o plano de recursos humanos - Desenvolver o plano de recursos humanos é o 
processo de identificar e documentar papéis, responsabilidades, habilidades necessárias e relações 
hierárquicas do projeto e criar um plano de gerenciamento de pessoal. 




Figura 9.4 - Mapa mental do processo Desenvolver o plano de recursos humanos 

Mobilizar a equipe do projeto - Mobilizar a equipe do projeto é o processo de confirmação da 
disponibilidade dos recursos humanos e obtenção da equipe necessária para concluir as designações 
do projeto. 













Figura 9.5 - Mapa mental do processo Mobilizar a equipe do projeto 

Desenvolver a equipe do projeto - Desenvolver a equipe do projeto é o processo de melhoria de 
competências, interação e ambiente global da equipe para aprimorar o desempenho do projeto. 



Figura 9.6 - Mapa mental do processo Desenvolver a equipe do projeto 

Gerenciar a equipe do projeto - Gerenciar a equipe do projeto é o processo de acompanhar o 
desempenho de membros da equipe, fornecer feedback, resolver questões e gerenciar mudanças para 
otimizar o desempenho do projeto. 



Figura 9.7 - Mapa mental do processo Gerenciar a equipe do projeto 

No gerenciamento de recursos humanos, é importante que se atente para os seguintes aspectos: 

• o trabalho em time é vital para o sucesso do projeto; 

• o espírito de corpo contribui para o sucesso; 

• co nfl itos podem ocorrer entre o projeto e a organização; 

• qualquer promessa feita durante o recrutamento deve ser documentada; 

• os níveis de equipes são muito mais variáveis em um ambiente de projeto que em um ambiente 
funcional; 

• treinamento e desenvolvimento são mais complexos e críticos durante o projeto, se 
comparados como trabalho tradicional da organização. 














1.41Plano de Gerenciamento de Recursos Humanos 


O Plano de Gerenciamento de Recursos Humanos é o documento formal que descreve os 
procedimentos que serão utilizados para gerenciar todos os recursos humanos do projeto. 

No plano deve estar documentado com: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• organograma do projeto mostrando a estrutura hierárquica do time do projeto, incluindo os 
elementos das estruturas matriciais relacionados; 

• diretório do time do projeto contendo todas as informações dos recursos humanos do projeto, 
incluindo cargo, área de atuação e contato; 

• matriz de responsabilidades relacionando os elementos do WBS com os integrantes do time; 

• políticas com relação a novos recursos, realocação e substituição de membros do time; 

• políticas de treinamento; 

• critérios de avaliação de resultados; 

• critérios de bonificação da equipe; 

• frequência de avaliação consolidada dos resultados do time; 

• alocação financeira para o gerenciamento de pessoal; 

• administração do plano de gerenciamento de pessoal; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento de recursos humanos; 

• outros assuntos relacionados ao gerenciamento de recursos humanos não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DAS 
COMUNICAÇÕES 




A grande maioria dos atritos, frustrações e ineficiências em nossas relações com as outras pessoas è causada pela pobreza nas comunicações. 



1.42Defínição 


Um efetivo processo de comunicação é necessário para garantir que todas as informações desejadas 
cheguem às pessoas corretas no tempo certo e de uma maneira economicamente viável. O gerente de 
projeto utiliza-se da comunicação para assegurar que o time do projeto trabalhe de maneira integrada 
para resolver os problemas do projeto e aproveitar suas oportunidades. 

Cleland define a comunicação como um processo pelo qual a informação é transferida entre os 
indivíduos através de símbolos, sinais e outros. Além disso, a comunicação é um processo de duas 
vias, onde participam ativamente o emissor e o receptor da informação, com os envolvidos atuando, 
na maioria das vezes, como emissores e receptores simultaneamente. 


Bnissor ■^ ^omunicaçâo ^^ Receptor 

Figura 10.1 - Processo de comunicação em duas vias 

As responsabilidades entre o emissor e o receptor podem ser assim distribuídas: 

Emissor - Responsável por produzir uma informação clara, de modo que o recebedor possa entendê- 
la com facilidade. 

Receptor - Responsável por tornar claro que a informação foi recebida e completamente 
compreendida. 

Além disso, é importante que também sejam avaliadas as barreiras no processo de comunicação, 
devido à percepção individual de cada um, bem como sua personalidade, atitudes, emoções, etc. A 
figura a seguir mostra o processo completo de comunicação, incluindo esses anteparos. 


Aflteparode Aroeoarooe 



Figura 10.2 - Processo de comunicação completo com anteparos, proposto por Kerzner e Cleland 

Com base nos trabalhos de Mintzberg sobre as estruturas das organizações, podem ser estabelecidos 
alguns fluxos no processo de trabalho provocados por diferentes mecanismos de comunicação entre 
as pessoas dentro de uma organização. São eles: 

Fluxo da Autoridade Formal - Onde a informação flui segundo uma hierarquia instituída dentro da 
organização ou projeto, realçando o fluxo do poder formal. 

Fluxo da Atividade Regulamentada - Onde a informação flui segundo um mecanismo padronizado 
de informação independente da hierarquia dos envolvidos. O foco desse fluxo é a padronização do 
processo de comunicação. 




































Fluxo das Comunicações Informais - Onde o processo de comunicação se dá sem a presença de 
nenhuma estrutura reguladora. As pessoas se agregam em grupos sociais ou de relacionamento e 
neles não existe hierarquia ou padronização. É o mais veloz e o mais arriscado mecanismo de 
comunicação. 

Conjunto das Constelações de Trabalho - Onde o processo de comunicação se dá através de 
objetivos claros e adequados a cada nível hierárquico da estrutura. Normalmente, as constelações de 
trabalho são os melhores modelos para o desenvolvimento do processo de comunicação em projetos. 

Fluxo do Processo Decisório Específico - Onde o processo de comunicação é necessário para 
decisões específicas, partindo da geração do problema até chegar à decisão específica a ser tomada. 



1.43Mindmap dos Processos de Gerenciamento das Comunicações 

Os processos de gerenciamento das comunicações se decompõem conforme o mapa mental a seguir. 
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Figura 10.3 - Mapa mental do Gerenciamento das Comunicações 





1.44Processos de Gerenciamento das Comunicações 


O PMBOK subdivide o gerenciamento das comunicações em cinco processos: 

• Identificar as partes interessadas (10.1); 

• Planejar as comunicações (10.2); 

• Distribuir as informações (10.3); 

• Gerenciar as expectativas das partes interessadas (10.4); 

• Reportar o desempenho (10.5). 
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Figura 10.4 - Processos de Gerenciamento das Comunicações distribuídos ao longo das fases do projeto 

Identificar as partes interessadas - É o processo de identificar todas as pessoas ou organizações 
que podem ser afetadas pelo projeto e de documentar as informações relevantes relacionadas aos 
seus interesses, envolvimento e impacto no sucesso do projeto. 



Figura 10.5 - Mapa mental do processo Identificar as partes interessadas 

Planejar as comunicações - Planejar as comunicações é o processo de determinar as necessidades 
de informação das partes interessadas no projeto e definir uma abordagem de comunicação. 




Figura 10.6 - Mapa mental do processo Planejar as comunicações 























Distribuir as informações - É o processo de colocar as informações necessárias à disposição das 
partes interessadas no projeto, conforme planejado. 


Figura 10.7 - Mapa mental do processo Distribuir as informações 

Gerenciar as expectativas das partes interessadas - Gerenciar as expectativas das partes 
interessadas é o processo de comunicação e interação com as partes interessadas para atender às 
suas necessidades e solucionar as questões à medida que ocorrerem. 






Figura 10.8 - Mapa mental do processo Gerenciar as expectativas das partes interessadas 

Reportar o desempenho - Reportar o desempenho é o processo de coleta e distribuição de 
informações sobre o desempenho, inclusive relatórios de andamento, medições do progresso e 
previsões. 


Figura 10.9 - Mapa mental do processo Reportar o desempenho 

No gerenciamento das comunicações, é importante que se atente para os aspectos a seguir: 

• As pessoas dão o melhor de si quando compreendem completamente as decisões que as afetam 
e suas razões. Elas precisam perceber o que têm de fazer e o porquê, o seu desempenho em 
relação ao esperado e a sua situação profissional; 

• se a base do gerenciamento de projetos é a formalização de processos para alcançar melhor 
desempenho, a informação e a comunicação não podem ser relegadas ao improviso e à intuição; 

• a decisão sobre o que comunicar, para quem e como deve ser incorporada a todas as fases do 




























planejamento; 

• os diferentes veículos de comunicação se complementam, combinando mensagens gerais e 
específicas para atingir diversos públicos; 

• informe sempre, em ocasiões regulares e com honestidade. Isso cria credibilidade para o 
processo; 

• nas situações de crise, seja ágil. Informe a posição atual, ainda que não seja a definitiva. 
Ninguém gosta de saber por último, e a falta de informações é fonte para boatos, criando 
instabilidade no projeto; 

• as pessoas não têm de concordar para cooperar com uma decisão, mas têm de compreender 
como e por que ela foi tomada. 



1.45Plano de Gerenciamento das Comunicações 


O Plano de Gerenciamento das Comunicações é o documento formal que descreve os procedimentos 
que serão utilizados para gerenciar todo o processo de comunicação no projeto. 

No plano, devem estar documentados: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento das comunicações; 

• eventos de comunicação (reuniões e apresentações); 

• cronograma dos eventos de comunicação; 

• atas de reunião; 

• exemplo de relatórios do projeto; 

• ambiente técnico e estrutura de armazenamento e distribuição da informação; 

• alocação financeira para o gerenciamento das comunicações; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento das comunicações; 

• outros assuntos relacionados ao gerenciamento das comunicações não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DE RISCOS 


Riscos devem ser assumidos somente quando os benefícios potenciais excedem os custos de correção de uma decisão tomada erroneamente. ” 


R. Max Wideman 



1.46Defínição 


Na maioria dos projetos, os riscos associados com grandes empreendimentos têm merecido uma 
atenção especial dos gerentes de projeto, devido não só às grandes somas de dinheiro que estão em 
suas mãos, como também à reputação do time e dos patrocinadores do projeto. 

Gerenciamento de riscos possibilita a chance de melhor compreender a natureza do projeto, 
envolvendo os membros do time de modo a identificar as potenciais forças e riscos do projeto e 
responder a eles, geralmente associados a tempo, qualidade e custos. Portanto, a sobrevivência de 
qualquer empreendimento, atualmente, está intimamente vinculada ao conceito de aproveitar uma 
oportunidade, dentro de um espectro de incertezas. O que torna a gestão dos riscos se tornar tão 
importante são fatores diversos, como o aumento da competitividade, o avanço tecnológico e as 
condições econômicas, que fazem com que os riscos assumam proporções muitas vezes 
incontroláveis. 
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Abrangência do Gerenciamento dos Riscos 


Figura 11.1 - Abrangência do Gerenciamento de Riscos (com base em Wideman) 

Todo risco necessita ser avaliado segundo dois aspectos: probabilidade de ocorrência e gravidade 
das consequências. Ao se multiplicar a probabilidade de um determinado risco acontecer com sua 
gravidade, normalmente expressa em valores de prejuízo financeiro, tem-se um conceito fundamental 
para a quantificação dos riscos denominado Valor Monetário Esperado (Earned Monetary Value). 
As prioridades na resposta ao risco serão para os eventos que apresentarem maior Valor Monetário 
Esperado. 

EMV = P x G 

onde P = Probabilidade 
G = Gravidade (valor monetário) 
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Figura 11.2 - Avaliação e quantificação de Riscos 








lAlMindmap dos Processos de Gerenciamento de Riscos 

Os processos de gerenciamento de riscos se decompõem conforme o mapa mental a seguir. 



Figura 11.3 - Mapa mental do Gerenciamento de Riscos 








1.48Processos de Gerenciamento de Riscos 


O PMBOK subdivide o gerenciamento de riscos em seis processos: 

• Planejar o gerenciamento dos riscos (11.1); 

• Identificar os riscos (11.2); 

• Realizar a análise qualitativa dos riscos (11.3); 

• Realizar a análise quantitativa de riscos (11.4); 

• Planejar as respostas aos riscos (11.5); 

• Monitorar e controlar os riscos (11.6). 
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Figura 11.4 - Processos de Gerenciamento de Riscos distribuídos ao longo das fases do projeto 

Planejar o gerenciamento dos riscos - Planejar o gerenciamento dos riscos é o processo de 
definição de como conduzir as atividades de gerenciamento dos riscos de um projeto. 
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Figura 11.5 - Mapa mental do processo Planejar o gerenciamento de riscos 

Identificar os riscos - Identificar os riscos é o processo de determinação dos riscos que podem 
afetar o projeto e de documentação de suas características. 

















Entradas 


11.2 - Identificar os riscos 


I Plano do goronciamomo dos rtscos 

■ 

J Estimativas do duração das atividados 

4 UinlM (M dO MCOpO 

5 Registro das partos interessadas 

I 6 Plano da garanciamonto doa cufttofi 
t Plano do goronc-ta monto do cronograma 

8 Plano do goroneiamonto da qualidade 

9 Documento» do projeto 

IO. Fatoros am biontars da omprosa 

II Ativo* iie priK^MNOM organi/acioriaia 


1 Registro dos ráOM 


Saídas 


Ferramentas 


1 Rhvdí^mh (ta docurnentaçAo 

2 T ecnicas do coleta do informações 

3 Anâliião da liatas da varlficaçAo 

4 Analiso do premissas 
5. Tdcnlcas da diagramas 

Análise de forças, fraquezas. 

6 oportunidade* a ameaça* < SWOT> 

7. Opinião especializada 


Figura 11.6 - Mapa mental do processo Identificar os riscos 

Realizar a análise qualitativa dos riscos - Realizar a análise qualitativa de riscos é o processo de 
priorização de riscos para análise ou ação adicional através da avaliação e combinação de sua 
probabilidade de ocorrência e impacto. 



Figura 11.7 - Mapa mental do processo Realizar a análise qualitativa dos riscos 

Realizar a análise quantitativa de riscos - Realizar a análise quantitativa de riscos é o processo de 
analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto. 


Figura 11.8 - Mapa mental do processo Realizar a análise quantitativa de riscos 

Planejar as respostas aos riscos - Planejar as respostas aos riscos é o processo de desenvolvimento 
de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. 















Figura 11.9 - Mapa mental do processo Planejar as respostas aos riscos 


Monitorar e controlar os riscos - Monitorar e controlar os riscos é o processo de implementação 
dos planos de respostas a riscos, acompanhamento dos riscos identificados, monitoramento dos 
riscos residuais, identificação de novos riscos e avaliação da eficácia do processo de riscos durante 
todo o projeto. 






Figura 11.10 - Mapa mental do processo Monitorar e controlar os riscos 

No gerenciamento de riscos, é importante que se atente para os seguintes aspectos: 

• Compreenda o projeto, produto ou processo a ser empreendido; 

• identifique os elementos do projeto sujeito a riscos; 

• desenvolva uma lista de ameaças e fraquezas para cada elemento; 

• priorize as ameaças e as fraquezas; 

• identifique impactos; 

• identifique os controles a serem adotados para evitar, ou minimizar, os impactos; 

• crie controles alternativos para quando os controles principais não forem efetivos, ou não 
puderem ser acionados; 

• gere sempre documentação para servir de base a futuros projetos. 













1.49Plano de Gerenciamento de Riscos 


O Plano de Gerenciamento de Riscos é o documento formal que descreve os procedimentos que 
serão utilizados para gerenciar os riscos através do projeto. O plano de riscos é um dos planos 
secundários do plano geral do projeto. 

No plano, devem estar documentados os seguintes dados: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento de riscos (regras gerais); 

• RBS - Risk Breakdown Structure para a Identificação dos Riscos; 

• riscos identificados; 

• qualificação dos riscos; 

• quantificação dos riscos; 

• sistema de controle de mudanças de riscos (Risk Change Control System ); 

• respostas planejadas aos riscos; 

• planos de contingência; 

• reservas de contingência; 

• frequência de avaliação dos riscos do projeto; 

• alocação financeira para o gerenciamento de riscos; 

• administração do plano de gerenciamento de riscos; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento de riscos; 

• outros assuntos relacionados ao gerenciamento de riscos não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



GERENCIAMENTO DAS AQUISIÇÕES 


O comprador sempre precisa ter vários olhos, o vendedor não precisa ter nenhum. ” 


George Herbert 



1.50Defínição 


O gerenciamento das aquisições tem como objetivo dar garantia ao projeto de que todo elemento 
externo participante do projeto irá garantir o fornecimento de seu produto, ou serviço, para o projeto. 

A relação entre o fornecedor e o projeto é determinada usualmente pela quantidade de riscos 
incorridos pelas partes. Normalmente, o custo de um determinado suprimento, ou contrato, está 
diretamente relacionado com o risco associado àquele trabalho. Por causa desse fator de risco, 
muitas vezes o custo não é o único elemento a ser analisado na negociação. O tipo de contrato 
também passa a determinar um papel fundamental no processo. Cada tipo de contrato representa certo 
grau de incerteza e riscos para o gerente de projeto. Os principais tipos de contratos estão listados a 
seguir. 

Contrato de Preço Fixo Global ( FFP - Firm Fixed Price ou Lump Sum Contract ) - Essa 
modalidade de contrato envolve um preço fixo total para produtos bem definidos. 

Contrato de Preço Fixo Global com Incentivo ( FPI - Fixed Price Incentive Contract) - Tipo de 
contrato em que o comprador paga ao vendedor uma quantia fixa (conforme estabelecido em 
contrato), e o vendedor poderá ganhar uma quantia adicional se satisfizer os critérios estabelecidos 
de desempenho. A essência desse tipo de contrato está na incerteza de quanto irá custar a realização 
do trabalho. Para tal, as partes acordam em uma meta de custos e uma participação de cada uma das 
partes do resultado. 

Contratos de Custo (Administração) com Incentivo sobre os Resultados ( CPIF - Cost Plus 

Incentive Fee) - Essa modalidade engloba o pagamento (reembolso) para o vendedor de seus custos 
reais acrescidos de um prêmio por economia, isto é, quanto mais o fornecedor economizar, maior 
será o seu bônus sobre o resultado, dentro de um limite mínimo e máximo de remuneração. 

Contratos de Custo (Administração) com Prêmio Fixo ( CPFF - Cost Plus Fixed Fee) - Esta 
modalidade engloba o pagamento (reembolso) para o vendedor de seus custos reais acrescidos de um 
valor fixo adicional como forma de remuneração. É o segundo menos desejável pela equipe do 
projeto porque não incentiva que o contratado economize, uma vez que o fornecedor não tem nada a 
ganhar ou perder comas economias ou desperdícios nas contratações e nos fornecimentos. 

Contratos por Administração ( CPPC - Cost Plus Percentage of Cost Contract) - Essa modalidade 
engloba o pagamento (reembolso) para o vendedor de seus custos reais acrescidos de um percentual 
desse custo como forma de remuneração. É o menos desejável pela equipe do projeto porque não 
incentiva que o contratado economize, uma vez que seu lucro é uma função dos custos incorridos, ou 
seja, quanto mais elevados forem os custos, mais o fornecedor ganha. 

Contrato por Preço Unitário (ilnit Price Contact) - Modalidade de contrato em que o vendedor 
recebe um montante por unidade de serviço (ex.: $20 por hora para serviços elétricos, ou $1 por 
metro cúbico de terra removida) e o valor total do contrato está em função das quantidades 
necessárias para concluir o trabalho. 

Com relação ao grau de risco para o fornecedor e para o comprador, tem-se o seguinte espectro de 
riscos: 
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Figura 12.1 - Tipos de contratos e riscos associados 

As estratégias para aquisições variam de empresa para empresa, podendo ser de responsabilidade da 
área de compras da empresa ou ser de responsabilidade do próprio projeto. 

Como os suprimentos normalmente estão fora do ambiente organizacional, eles podem variar de 
acordo com a facilidade que se tem para obtê-los e com a quantidade de fornecedores capacitados 
para tal. A figura a seguir mostra o espectro estrutural do mercado. 
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Figura 12.2 - Espectro estrutural do mercado 






















1.51 Mindmap dos Processos de Gerenciamento das Aquisições 

Os processos de gerenciamento das aquisições se decompõem conforme o mapa mental a seguir. 
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Figura 12.3 - Mapa mental do Gerenciamento das Aquisições 




1.52Processos de Gerenciamento das Aquisições 


O PMBOK subdivide o gerenciamento das aquisições em quatro processos: 

• Planejar as aquisições (12.1); 

• Conduzir as aquisições (12.2); 

• Administrar as aquisições (12.3); 

• Encerrar as aquisições (12.4). 


GERENCIAMENTO DAS AQUISIÇÕES 
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Figura 12.4 - Processos de Gerenciamento das Aquisições distribuídos ao longo das fases do projeto 

Planejar as aquisições - Planejar as aquisições é o processo de documentação das decisões de 
compras do projeto, especificando a abordagem e identificando fornecedores em potencial. 
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Figura 12.5 - Mapa mental do processo Planejar as aquisições 

Conduzir as aquisições - Realizar as aquisições é o processo de obtenção de respostas de 
fornecedores, seleção de um fornecedor e adjudicação de um contrato. 
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Figura 12.6 - Mapa mental do processo Conduzir as aquisições 















Administrar as aquisições - Administrar as aquisições é o processo de gerenciar as relações de 
aquisição, monitorar o desempenho do contrato e fazer mudanças e correções conforme necessário. 



Figura 12.7 - Mapa mental do processo Administrar as aquisições 

Encerrar as aquisições - Encerrar as aquisições é o processo de finalização de cada aquisição do 
projeto. Como envolve verificar se todo o trabalho e as entregas são aceitáveis, serve de apoio ao 
processo de encerramento do projeto ou a fase. 


Figura 12.8 - Mapa mental do processo Encerrar as aquisições 

No gerenciamento das aquisições, é importante que se atente para os seguintes aspectos: 

• utilize um checklist para a preparação de propostas e contratos; 

• avalie os riscos antes de escolher um determinado tipo de contrato; 

• sempre reveja, como departamento jurídico, o contrato a ser assinado; 

• garanta, através de contrato ou seguro, os riscos não cobertos. 











1.53Plano de Gerenciamento das Aquisições 


O Plano de Gerenciamento das Aquisições é o documento formal que descreve os procedimentos que 
serão utilizados para gerenciar todos os contratos do projeto. 

No plano, devem estar documentados os seguintes fatores: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• descritivo dos processos de gerenciamento das aquisições (regras gerais), incluindo quais 
elementos serão objeto de contrato; 

• gerenciamento e tipos de contratos; 

• critérios de avaliação de cotações e propostas; 

• avaliação de fornecedores; 

• frequência de avaliação dos processos das aquisições; 

• alocação financeira para o gerenciamento das aquisições; 

• administração do plano de gerenciamento das aquisições; 

• nome do responsável pelo plano; 

• frequência de atualização do plano de gerenciamento das aquisições; 

• outros assuntos relacionados ao gerenciamento das aquisições não previstos no plano; 

• registro de alterações no documento; 

• aprovações. 



QUESTÕES PARA REVISÃO 


1. Qual é a diferença entre garantia e controle da qualidade? 

2. Quais as diferenças na aplicação da análise qualitativa e quantitativa de riscos? Cite 
vantagens e desvantagens de cada uma. 

3. Qual tipo de escopo é descrito em uma EAP? 

4. Explique os tipos profissionais requeridos no time de projeto em função das fases do projeto. 

5. Diferencie os tipos de contrato e seus riscos associados. 

6. Explique os elementos 5W e 2H para a criação do plano de comunicação do projeto. 

7. Qual é a diferença entre estimativas de custos e orçamentação? 

8. Como é realizado o planejamento de recursos e qual sua relação com o gerenciamento de 
recursos humanos? 

9. Diferencie escopo técnico de escopo funcional. 
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Áreas do PMBOK Guide 3rd Edition 
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Existem duas formas de ser criativo. A primeira é cantar e dançar. A segunda è preparar o ambiente para que as pessoas dancem e cantem. ” 

Warren Bennis 

Muitas vezes, ao se trabalhar com projetos, o executivo deve estar atento ao fato de que o projeto faz 
parte de um todo organizado e está sujeito às influências da cadeia de poder. A autonomia do gerente 
de projeto está sempre limitada aos interesses da empresa. Infelizmente, a grande maioria está pouco 
preparada para lidar com essas estruturas organizacionais. 

Todo projeto está imerso em uma determinada hierarquia de sistemas que precisa ser constantemente 
respeitada pelo gerente de projeto. Não se pode considerar o projeto mais importante que a própria 
organização ou, até mesmo, maior que o meio ambiente que cerca todas as organizações. 
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Figura 1.1 - A hierarquia dos sistemas proposta por Kerzner 

O estilo organizacional apropriado para um projeto específico depende quase que totalmente de sua 
natureza e do estilo organizacional da empresa. Para que o projeto seja estruturado efetivamente, o 
gerente de projeto deve compreender não somente as opções organizacionais disponíveis, mas 
também os resultados prováveis da implementação do projeto dentro da organização em inúmeros 
aspectos. 

As estruturas organizacionais refletem-se diretamente nos projetos por elas gerenciados, uma vez que 
a importância dada ao assunto do projeto, a disponibilidade dos envolvidos e o interesse da 
organização são influenciados diretamente pela natureza da estrutura organizacional adotada pela 
empresa. 

Dentre as principais estruturas, destacam-se: 

• organizações funcionais; 

• organizações matriciais leves com expedidor de projetos; 



• organizações matriciais leves com coordenador de projetos; 

• organizações matriciais balanceadas; 

• organizações matriciais fortes; 

• organizações por projetos. 

A maioria das empresas modernas envolve todas essas estruturas ao mesmo tempo em seus 
organogramas, havendo desde setores onde a estrutura é totalmente funcional até departamentos 
inteiros com estrutura voltada completamente para projetos. Essas estruturas são denominadas 
estruturas compostas ou mistas. 
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Tabela 1.1 - A estrutura organizacional e sua influência nos projetos (PMBOK Guide 4 a Edição) 

É importante ressaltar que várias propostas de alternativas organizacionais retratam o processo de 
maneira bastante simplista, onde, com uma ou duas perguntas, ousa-se determinar os parâmetros 
organizacionais de uma companhia. Na verdade, é necessária uma análise muito mais cuidadosa, no 
intuito de assegurar que determinada alternativa organizacional é a melhor opção para uma 
organização em um dado momento. Nos próximos capítulos serão apresentados alguns modelos de 
organizações como objetivo de expor determinados comportamentos organizacionais. 














1.540rganizações não Baseadas em Projetos 


Normalmente as empresas são voltadas para a fabricação de um determinado bem ou a prestação de 
algum tipo de serviço. Nesses tipos de organização, os projetos são utilizados apenas para apoiar as 
linhas de produtos ou serviços. São, na maioria das vezes, empresas com pequeno desenvolvimento 
tecnológico e, portanto, um eventual líder de projeto tem mais dificuldades para conduzir os 
trabalhos, já que os projetos não fazem parte da lista de prioridades da organização. 

Algumas companhias não baseadas em projetos possuem departamentos, ou empresas terceirizadas, 
que atuam como empresas orientadas para projetos no intuito de suprir esses esforços localizados. 
São algumas características das organizações não baseadas em projetos as seguintes: 

• os gerentes e responsáveis não têm disponibilidade, ou tempo, para atuar em projetos. A 
necessidade principal da empresa é o suporte ao processo produtivo; 

• a autoridade do gerente funcional é superior à autoridade do gerente de projeto, dificultando o 
controle da equipe por parte do gerente de projeto; 

• a equipe do projeto não é compreendida e respeitada pelo restante da empresa; 

• o pequeno investimento da organização em treinamento e capacitação das equipes que 
trabalharão nos projetos; 

• a grande necessidade de obtenção de conhecimento externo para gerenciar os projetos 
(consultorias). 



1.550rganizações Baseadas em Projetos 


São organizações onde o trabalho é totalmente caracterizado por projetos e, portanto, cada um desses 
projetos possui um controle próprio. O trabalho da empresa consiste em agregar todos esses 
projetos. Exemplos típicos de empresas baseadas em projetos são as empresas de construção civil e 
as empreiteiras, empresas de desenvolvimento de software e produtos, indústria aeroespacial, 
empresas de desenvolvimento de produtos, empresas de marketing e de consultoria, dentre outras. 

São características das organizações baseadas em projetos as seguintes: 

• os gerentes e responsáveis têm disponibilidade, ou tempo, para atuarem em projetos, uma vez 
que sua função principal é gerenciar os projetos; 

• a autoridade do gerente de projeto é absoluta, assumindo, também, o controle funcional dos 
envolvidos, permitindo a integração e o controle por uma única pessoa; 

• grande parte dos funcionários da organização é integrante de algum projeto; 

• elevado investimento da organização em treinamento e capacitação das equipes de projetos; 

• necessidade de apoio externo (consultorias) para gerenciar os projetos somente em casos 
complexos. 



ESTRUTURA ORGANIZACIONAL 
FUNCIONAL 


Estruturas funcionais são perigosas porque os conflitos tendem a aumentar entre as prioridades relativas dos diferentes projetos concorrendo por recursos limitados. ” 


Robert Youker 

Este modelo organizacional se caracteriza por utilizar a mesma linha de controle para projetos e 
rotina. É marcado pela presença da hierarquia funcional na organização. Os projetos são conduzidos 
por equipes pertencentes a cada departamento, e suas responsabilidades são limitadas pelas 
fronteiras de suas funções. A importância dada aos projetos é pequena e as tarefas desempenhadas 
normalmente têm algum vínculo funcional como envolvido. 

As vantagens de utilizar estruturas funcionais para gerenciar um projeto são as seguintes: 

• familiaridade do time em trabalho conjunto, uma vez que as posições estão previamente 
definidas; 

• as políticas administrativas já estão compreendidas pelo grupo; 

• a disponibilidade de equipe é controlada pelo gerente funcional, reduzindo os conflitos; 

• eficiência no controle e otimização de cronogramas, já que as pessoas podem trabalhar em 
projetos e rotina ao mesmo tempo, alternando entre atividades de projeto e rotina quase que 
instantaneamente; 

• autoridade claramente definida pela hierarquia funcional. 

As desvantagens da estrutura funcional são as seguintes: 

• recursos limitados à esfera departamental; 

• burocracia elevada para o projeto, ao utilizar o fluxo do processo de trabalho da empresa; 

• perda de foco no projeto devido ao foco ser dividido coma rotina; 

• orientação departamental do projeto, ou seja, as prioridades do departamento passam a ser as 
do projeto. 



































ESTRUTURA ORGANIZACIONAL POR 
PROJETOS 


Tudo está em constante mutação e cada mudança parece um aprimoramento. ” 


Aléxis de Tocqueville 

Modelo organizacional caracterizado por uma estrutura quase exclusiva de projetos na organização, 
englobando toda a parte funcional da organização dentro de cada projeto. Nessas organizações, os 
projetos são conduzidos por gerentes de projeto que se dedicam em tempo integral ao projeto e têm 
autonomia total, inclusive responsabilidade com as atividades de gerente funcional perante os 
membros do projeto. Têm uma equipe administrativa que se dedica integralmente ao projeto. Os 
projetos são a razão de ser da empresa. Essas organizações normalmente têm departamentos 
administrativos que se reportam diretamente aos gerentes de projeto e têm como objetivo único dar 
suporte aos projetos da empresa. 

As vantagens de utilizar estruturas de projeto são as seguintes: 

• clara definição de autoridade através da presença do gerente de projeto; 

• processo de comunicação simplificado porque todas as pessoas se reportam ao mesmo gerente 
de projeto, que está focado nas metas e nos objetivos do projeto; 

• desenvolvimento de especialidades como aprendizado na atividade de projetos; 

• a empresa voltada para projeto tem foco e prioridade diferenciados para seus projetos, dando 
força para a busca do atingimento das metas e dos objetivos. 

As desvantagens da estrutura de projetos são os seguintes: 

• duplicação de esforços em projetos com igualdade de prioridades sendo desenvolvidos ao 
mesmo tempo; 

• no término do projeto, corre-se o risco de perda da equipe em função da insegurança criada; 

• competição interna na empresa por poder e recursos; 

• dificuldade na reintegração das pessoas da equipe à estrutura convencional da empresa com o 
fim do projeto. 




Figura 3.1 - Estrutura por Projetos com destaque para todos os funcionários alocados em projetos 

















ESTRUTURA MATRICIAL LEVE 


Nas estruturas matriciais leves, muitas vezes, a única pessoa leal ao projeto é seu expedidor ou coordenador. " 


Dwayne Cable 

Estrutura caracterizada pela alocação de pessoas na condução de projetos com uma pequena 
autoridade formal sobre as atividades e os recursos do projeto. Esse administrador, coordenador ou 
expedidor do projeto é, basicamente, um staff dos executivos, que tem a responsabilidade 
operacional sobre o projeto. Estrutura usada apenas quando o projeto é relativamente pequeno e 
simples, ou essa iniciativa é a primeira iniciativa de gerenciamento de projetos da empresa. 

E caracterizada também pela presença da hierarquia funcional na organização, porém sem a mesma 
força das estruturas funcionais clássicas. Representa uma mistura de características funcionais e de 
projetos. A importância dada aos projetos ainda é pequena. 

As principais atribuições desse profissional são os seguintes: 

• identificar áreas críticas; 

• propor soluções de problemas; 

• encaminhar as decisões de dentro para fora e de fora para dentro do projeto; 

• promover a comunicação entre os integrantes do time; 

• apoiar o gerenciamento do projeto com regularidade. 
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Figura 4.1 - Estrutura Matricial Leve 


































ESTRUTURA MATRICIAL BALANCEADA 


A estrutura matricial balanceada sempre cria uma situação de conflitos entre o projeto e a linha funcional. ” 


John R. Adams 

Estrutura caracterizada pela alocação de um gerente de projetos formal para conduzir o trabalho no 
projeto. Esse coordenador ou gerente de projeto passa a ter, agora, um conjunto maior de 
responsabilidades e é encarregado de coordenar diversas atividades do projeto. Estrutura usada não 
só apenas quando o projeto ainda é relativamente pequeno e simples, como também nas primeiras 
experiências de gerenciamento de projetos da empresa. Grande cuidado deve ser tomado com os 
níveis de conflitos que possam ser gerados entre as áreas funcionais e as de projetos. 

Como no caso da estrutura matricial leve, esse modelo é também caracterizado pela presença da 
hierarquia funcional na organização, porém sem a mesma força das estruturas funcionais clássicas. 
Representa uma mistura de características funcionais e de projetos. A importância dada aos projetos 
ainda é limitada. 

As principais atribuições desse profissional são as seguintes: 

• atribuir atividades aos elementos da estrutura funcional; 

• compartilhar autoridade e decisões como gerente funcional; 

• controlar o atingimento das metas e dos objetivos estabelecidos; 

• promover a comunicação entre os integrantes do time e entre o projeto e a organização. 



Figura 5.1 - Estrutura Matricial Balanceada 










ESTRUTURA MATRICIAL FORTE 
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A estrutura matricial se tornou um dos mais populares modelos para gerenciar projetos em um ambiente de múltiplos projetos. ” 

Vijay K Verma 

Com o crescimento da importância dada ao gerenciamento de projetos pela organização, torna-se 
necessária uma estrutura que comporte as características funcionais e as de projetos em diferentes 
proporções, resultando em um sistema autoridade/responsabilidade/disponibilidade misto dentro da 
empresa. Nessas organizações, os projetos são conduzidos por gerentes de projeto que se dedicam 
em tempo integral ao projeto e têm autonomia comparável à do gerente funcional. Esses gerentes de 
projeto se agrupam em um departamento ou área da empresa que se destina ao gerenciamento dos 
projetos da empresa, que por sua vez passam a ser importantes e estratégicos para o negócio. 



Figura 6.1 - Estrutura Matricial Forte 












































PROJECT MANAGEMENT OFFICE 


O tempo de mudar é agora. Nunca é tarde para se fazer alguma coisa. ” 


Cari Sandburg 

Atualmente várias organizações estão adotando estruturas de Escritórios de Projetos ( Project Office ) 
em suas atividades de gerenciamento de projetos. Escritórios de projeto têm como objetivo 
prioritário suportar os projetos, visando aumentar o nível de maturidade organizacional e 
consequentemente, aumentar a taxa de sucesso desses projetos. 

O Escritório do Projeto é um local central para conduzir, planejar, organizar, controlar e finalizar as 
atividades do projeto. 

A função do escritório em uma organização pode variar de uma assessoria, limitada à recomendação 
de políticas e procedimentos para projetos individuais, até uma estrutura gerencial completa, que, 
além de administrar os projetos específicos, irá estabelecer as políticas aplicáveis a projetos e a 
gestão estratégica desses empreendimentos. 

O Escritório do Projeto é também um centro de informações e controle que contém gráficos, 
diagramas, documentação e cronogramas. Ele mostra essas informações emparedes, quadros brancos 
e negros, computadores etc. Ele também é a casa do time do projeto, onde todo o suporte está 
disponível. Vários autores chamam o Escritório do Projeto de QG (Quartel General). Ele deve ser 
montado sempre antes do início do projeto. 

O crescimento do interesse pelos escritórios de projeto é decorrente de várias razões específicas, 
dentre elas podem ser destacadas as seguintes: 

Inexistência de padrão para reportar desempenho - Não existe um padrão uniforme de 
desempenho, com isso as atividades de avaliação e comparação entre projetos fica seriamente 
prejudicada. 

Sobrecarga dos gestores - Os gestores de projeto estão sobrecarregados e o escritório de projetos 
fornece a informação que suporta a decisão. 

Aumento na complexidade e dinâmica dos projetos - Devido ao ambiente cada vez mais complexo 
dos projetos, a necessidade de apoio especializado no controle dos empreendimentos contribui 
significativamente para o sucesso dos trabalhos. 

Lições aprendidas não são documentadas - As organizações precisam cada vez mais registrar as 
lições aprendidas nos projetos para conseguir construir diferenciais competitivos sustentáveis. 

Os principais objetivos do Escritório do Projeto são: 

• centralizar as informações; 

• estabelecer políticas e procedimentos para projetos; 

• ser um centro de apoio ao time; 

• representar fisicamente o projeto; 

• estimular o espírito de corpo do time. 

Suas principais funções administrativas são: 

• gerenciamento de cronogramas; 

• geração e elaboração de documentos e relatórios do projeto; 



• atuar como a Sala de Situação ou War Room\ 

• manutenção de histórico do projeto; 

• operação de ferramentas computacionais e softwares de gerenciamento de projetos. 



Figura 7.1 - Exemplo de layout simplificado de um escritório de projetos, evidenciando os seus principais papéis no 
gerenciamento dos projetos 






















































































1.56Tipos de PMO 


Existem basicamente três níveis de escritórios de projeto de acordo com a finalidade e a 
característica de atuação desejada pela organização: 

Projeto Autônomo - Escritório de projeto separado das operações da empresa, destinado ao 
gerenciamento de um projeto ou programa específico, onde a responsabilidade quanto ao sucesso ou 
fracasso do projeto é do PMO. Conhecido também como PMO de Projeto Isolado. 



Figura 7.2 - Modelo de PMO para projeto autônomo 

Project Support Office - Escritório de projeto de esfera departamental destinado ao apoio a 
diversos projetos simultâneos, fornecendo suporte, ferramentas e serviços de planejamento, controle 
de prazos, custos, qualidade, dentre outros. Também pode fornecer recursos técnicos, metodologia de 
gerenciamento de projetos, metodologia de gestão do conhecimento, interfaces organizacionais, 
tornando-se um centro de competência em projetos. Conhecido também como PMO Departamental. 





























































































Figura 7.3 - Modelo de PMO para Project Support Office 

Enterprise Project Support Office - Escritório de projetos de esfera corporativa, atuando no 
gerenciamento estratégico de todos os projetos da organização. Suas principais funções são o 
planejamento estratégico dos projetos, o gerenciamento dos projetos corporativos e 
interdepartamentais, a gestão do conhecimento empresarial em projetos, além de representar a 
interface entre os envolvidos no projeto. Quando engloba atividades relacionadas ao conjunto de 
projetos, tais como a priorização de projetos e alinhamento estratégico, é comumente chamado de 
Enterprise Portfolio Management Office (EPMO) 



Figura 7.4 - Modelo de PMO para Enterprise Project Support Office 

















































1.57Constituindo um PMO 


Um assunto com grande popularidade na área de projetos diz respeito aos procedimentos de criação 
do escritório de projeto. Diversos autores criaram metodologias próprias para a implantação do 
escritório de projetos. Tomando por base os trabalhos de Block & Frame e de Crawford, têm-se oito 
passos básicos de implementação, a saber: 

1. Escolha do tipo de escritório a ser implementado 

2. Obtenção do suporte e apoio necessário (patrocinador) 

3. Criação da inffaestrutura do escritório (instalações, funcionamento, etc.) 

4. Motivar e doutrinar envolvidos 

5. Programar estrutura (relatórios, análises, ferramentas, etc.) 

6. Estabelecer projeto-piloto 

7. Entrada em operação 

8. Feedbacke melhoria contínua 



QUESTÕES PARA REVISÃO 


1. Diferencie as estruturas matriciais leves das estruturas funcionais. 

2. Diferencie a abrangência do Project Support Office e Enterprise Project Support Office. 

3. Compare as desvantagens da estrutura funcional com a estrutura por projetos. 

4. Por que a estrutura matricial é caracterizada por um elevado nível de conflitos? 

5. Por que mesmo em uma estrutura de projetos pode existir um percentual da organização não 
dedicado a projetos? 

6. Analise e compare os critérios de alocação do gerente de projeto com seu cargo e posição na 
empresa. 



PALAVRA CRUZADA 


Preparando a Organização 


r . .1.. 
r í 1 



1 


Across 

2 Responsável pela 
administração do projeto 
nas estruturas funcionais 

4 Escritório de projeto 
separado das 
operações da empresa, 
destinados ao 
gerenciamento de um 
projeto ou programa 
especifico 

6 Alocação da equipe 
administrativa do projeto 
nas organizações por 
projetos 


Down 

1. Escritório de projeto 
de esfera 
departamental 

3. Uma problema a ser 
administrado na 
estrutura matricial 

4. Centro de informações 
e controle do projeto 
(sigla) 

5 Alocação do 
coordenador do 
projeto nas estruturas 
matriciais leves 


Respostas disponíveis no final do livro - Anexo II 





- PARTE V - O GERENTE DE PROJETOS E SUAS 

INTERFACES 



1. DEFINIÇÕES E HABILIDADES DO 
GERENTE DE PROJETOS 


Como gerente de projetos, você tradicionalmente tem muito mais responsabilidades do que autoridade. ” 


Michael S. Dobson 

Muito do sucesso ou fracasso de um projeto está no gerente do projeto. Ele será o responsável por 
planejar, implementar e completar o projeto, iniciando seus trabalhos assim que o projeto começa. 
Normalmente, o gerente do projeto tem que controlar o escopo complexo, envolvendo centenas de 
pessoas, milhares de atividades e, muitas vezes, milhões de dólares. 

Um dos principais riscos que se pode encontrar, atualmente, é a convicção que algumas pessoas têm 
de que, com softwares de planejamento, elas se tornarão gerentes de projeto instantâneos. 

Mesmo podendo desempenhar outras atividades funcionais na organização (estruturas funcionais ou 
matriciais leves), o gerente de projeto é o responsável último pelo sucesso do projeto, tendo uma 
série de demandas quase que exclusivas, incluindo: 

• produzir o produto final do projeto dentro dos prazos, custos e desempenho exigidos; 

• atingir objetivos contratuais de lucro; 

• adquirir os recursos adequados para o projeto, em quantidade e qualidade; 

• contratar e motivar os integrantes do time; 

• lidar com obstáculos e possibilidades de fracasso, usando precisão e energia; 

• gerir estrategicamente os riscos do projeto; 

• desenvolver canais de comunicação efetivos; 

• desenvolver mecanismos de negociação com todos os elementos internos e externos do projeto 
para garantir o cumprimento do plano do projeto. 

Gerentes de projeto, diferente dos gerentes funcionais, não têm poder para alcançar seus objetivos 
sozinhos. Eles dependem dos seus superiores, subordinados e pares para distribuir os esforços para 
tornar o projeto bem sucedido. Então, por que alguns indivíduos são mais bem-sucedidos como 
gerentes de projetos do que outros? A resposta pode ser simples. Eles conseguem esses sucessos 
porque possuem algumas competências específicas, dependentes de um conjunto amplo de fatores, 
muitos dos quais têm muito pouca ou nenhuma relação direta com habilidades técnicas. 

Dentre essas habilidades, podem ser destacadas as seguintes: 

• Habilidades nas comunicações 

• Habilidade de escutar 

• Habilidade de persuadir 

• Habilidades organizacionais 

• Planejamento 

• Estabelecimento de objetivos 

• Análise 

• Habilidades no Gerenciamento do time 



• Empatia 

• Motivação 

• Espírito de corpo 

• Lealdade 

• Ética 

• Habilidades de liderança 

• Ser exemplo constante 

• Energia 

• Visão 

• Delegação 

• Atuação otimista 

• Habilidades internas 

• Flexibilidade 

• Criatividade 

• Paciência 

• Persistência 

Um estudo de Mulcahy (2002) comprova também que as características relacionadas às habilidades 
pessoais e ao gerenciamento de times são consideradas as mais importantes por um grupo de 1041 
gerentes de projetos pesquisados. A tabela a seguir mostra os resultados encontrados. 



Item 

Respostas 

Grupo de Habilidades 

Habilidade de comunicação 

101 

Pessoais 

Organização 

71 

Pessoais 

Visão direta nos resultados 

58 

Trabalho em grupo 

Liderança pelo exemplo 

53 

Trabalho em grupo 

Habilidades interpessoais 

47 

Trabalho em grupo 

Motivação 

32 

Trabalho em grupo 

Capacidade de escutar 

24 

Trabalho em qrupo 

Comprometimento com o time 

22 

Trabalho em grupo 

Flexibilidade 

22 

Pessoais 

Planejamento 

21 

Gerenciamento de Projetos 

Compreensão de que cada projeto é único 

20 

Gerenciamento de Projetos 

Adequada definição de requerimentos 

19 

Gerenciamento de Projetos 

Senso de humor 

19 

Pessoais 

Reputação e integridade 

19 

Pessoais 

Honestidade 

17 

Pessoais 

Capacidade de negociação 

17 

Técnicas 

Expenéncia técnica no assunto 

15 

Técnicas 

Perseverança 

13 

Pessoais 

Paciência 

12 

Pessoais 

Visão 

11 

Pessoais 

Capacidade de lidar com os outros 

10 

Trabalho em grupo 

Atitude otimista e positiva 

10 

Pessoais 

Planejamento do escopo das comunicações 

9 

Gerenciamento de Projetos 

Planejamento para mudanças inesperadas 

9 

Gerenciamento de Projetos 

Capacidade de reconhecer e recompensar 

9 

Trabalho em grupo 

Atenção para os detalhes 

9 

Pessoais 

Manter foco nas principais pendências e 
questões 

8 

Gerenciamento de Projetos 

Delegação 

8 

Pessoais 

Dedicação 

8 

Pessoais 

Energia 

8 

Pessoais 

Entusiasmo 

8 

Pessoais 

Foco 

8 

Pessoais 


Tabela 1.1 - Quadro das habilidades do gerente de projeto (Mulcahy, 2002) 






































SELECIONANDO O GERENTE DE 
PROJETOS 


íí 

O gerente de projeto peifeito vale o seu peso em ouro. ” 


Ralph L. Kliem 

Provavelmente, é uma das mais difíceis decisões que a alta direção da organização precisa tomar. O 
gerenciamento de projetos não será realizado com sucesso sem bons gerentes de projeto. 

O processo de seleção do gerente de projeto deve considerar algumas questões: 

• Quais são os potenciais candidatos? 

• Como eles serão selecionados? 

• Como serão desenvolvidas carreiras em gerenciamento de projetos? 

• Como serão desenvolvidas habilidades de gerenciamento de projetos? 

• Como será avaliado o desempenho do gerente de projeto? 

Três pilares sustentam a seleção do mais adequado gerente de projeto: 

• habilidades; 

• motivação; 

• personalidade. 



Figura 2.1 - Pilares da seleção do gerente de projeto 

Jeffrey Pinto e Jefírey Trailer listaram um conjunto de fatores que precisam ser avaliados durante a 
seleção do gerente de projetos, estratificado segundo conjuntos de habilidades: 

A-Resolução de problemas 

1. Análise do Problema 

• Habilidades conceituais e mentais 

• Habilidade de gerenciar grande quantidade de informação ao mesmo tempo 

• Capacidade de identificar problemas 

• Capacidade de encontrar sintomas para identificar as causas 

• Capacidade de análise dos dados essenciais para a tomada de decisões 

• Habilidade no desenvolvimento de todas as possíveis soluções e suas consequências 


2. Julgamento e Senso Prático 

• Escolher entre as possíveis soluções a mais adequada 

• Tomar decisões que levam em consideração as restrições do projeto e de seu ambiente 

• Sempre ter em mente a perspectiva global do projeto, e não apenas uma de suas faces 

3. Capacidade de Decisão 

• Propensão a tomar decisões 

• Comprometimento com as decisões, até mesmo em situações delicadas e complexas 

• Configurar uma estratégica concreta de implantação da decisão 
B - Administração 

4. Planejamento e Organização 

• Identificar objetivos e prioridades 

• Estabelecer distribuição do trabalho no tempo 

• Organizar os recursos para atingir os objetivos 

• Definir as atividades e seus métodos de trabalho 

5. Controle 

• Manter controle diário sobre as atividades em relação às datas de término previstas 

• Garantir ações corretivas imediatas se necessário 

• Acompanhar os orçamentos e exercer controle financeiro 

6. Estratégia e Know-How Organizacional 

• Manter-se sempre bem informado 

• Construir redes de colaboração informal e formal 

• Conhecer os elementos externos ao projeto (fornecedores e serviços) 

• Conhecer a organização e suas operações 

• Ter habilidade de trabalhar em harmonia com a realidade da organização 

• Ter habilidade de empregar terceiros para atingir objetivos 

7. Conhecimento Especializado 

• Conhecer as informações, os princípios, as teorias e as técnicas que são úteis para o projeto e 
para as demais áreas (finanças, contratos, marketing, etc.) 

C - Supervisão e Gerenciamento do Time 

8. Delegação de Responsabilidades 

• Acreditar sempre no trabalho das outras pessoas 

• Estruturar claramente as tarefas a serem realizadas e permitir a iniciativa do time nos 
trabalhos 

• Delegar as responsabilidades nos níveis apropriados 

• Compartilhar parte das responsabilidades com o time 

• Alocar autoridade e recursos para que o time possa tomar decisões significativas em suas 
áreas de atuação 

• Ter habilidade para trabalhar com subordinados que têm especializações específicas em 
determinadas áreas sem ser submisso ou negligente 




9. Estruturação do Time 

• Estruturar as tarefas a serem realizadas e comunicá-las claramente ao time 

• Ter habilidade de utilizar seu poder unilateralmente 

• Usar reforços para estimular o time 

• Estabelecer controles que favorecem a conclusão das atividades de acordo cornos objetivos 

10. Consideração como Time 

• Ter consideração pelas pessoas que compõem o time 

• Identificar suas necessidades e garantir sua satisfação 

• Ser amável e educado com as pessoas 

11. Desenvolvimento do Time 

• Realizar avaliações de desempenho periódicas e dar feedback 

• Identificar as necessidades de treinamento com base em suas atividades atuais e futuras 

• Criar estratégias de treinamento 

• Demonstrar importância ao treinamento através da liberação de verbas, pessoas e até mesmo 
tempo pessoal para atividades de treinamento 

12. Trabalho em Time, Flexibilidade e Cooperação 

• Ter capacidade de trabalhar como parte de um grupo 

• Reconhecer as circunstâncias que requerem trabalho em time ou decisão em time 

• Ser receptivo aos outros pontos de vista 

• Estar preparado para mudar a própria opinião 

13. Resolução de conflitos 

• Ter habilidade de coordenar especialistas de diferentes áreas 

• Reconhecer uma situação de conflito e resolvê-la da maneira mais eficiente 

• Conhecer a psicologia dos conflitos 
D - Relações Interpessoais 

14. Comunicação Oral 

• Comunicar eficientemente em conversas 

• Realizar apresentações de qualidade 

• Concretizar as comunicações a respeito do projeto 

15. Influência, Persuasão e Negociação 

• Estar ciente dos sentimentos, das necessidades e das expectativas dos demais 

• Ter consciência dos efeitos da conduta de uns nos outros 

• Ter habilidade de influenciar os demais para atingir os objetivos 

• Trazer o interlocutor para o seu ponto de vista enquanto mantém um bom relacionamento 

16. Ascendência Sobre os Demais 

• Gostar de comandar 

• Ter necessidade de dominar os demais sem ser dominado 

• Estar ciente das influências de alguns sobre os demais 



E - Outras Habilidades Pessoais 

17. Necessidade de Proatividade 

• Ter sempre a necessidade de atingir algo único 

• Ter constante desejo de fazer o melhor e de ser o melhor 

• Transformar diretamente ações em resultados 

• Ter dinamismo e energia 

• Ter otimismo para acreditar na capacidade de influenciar os eventos ao seu redor 

18. Autoconfiança, Maturidade e Estabilidade Emocional 

• Confiar em si mesmo e em sua capacidade 

• Estar pronto para lidar com as consequências pessoais diante da dificuldade nas decisões 

• Ter estabilidade emocional e força 

• Ter capacidade de controlar emoções 

• Ter resistência ao estresse no curto e no longo prazo 

19. Lealdade, Honestidade e Integridade 

• Apoiar as políticas e os valores da organização 

• Colocar os interesses da companhia antes dos interesses próprios 

• Respeitar os superiores 

• Respeitar as obrigações 

• Ter integridade pessoal e profissional 

20. Tolerância diante da Ambiguidade e Abertura à Mudança 

• Aceitar as incertezas e as situações adversas que ocorrem inevitavelmente no projeto 

• Desejar trabalhar em organizações flexíveis como as matriciais ou suas variantes 

• Ter propensão a alterar planos, aproximações, estratégias, políticas ou práticas de acordo com 
as demandas do projeto e da organização 

21. Interesse pelo Trabalho 

• Ser motivado pelo trabalho 

• Ter esperança de que seu plano de carreira corresponda às oportunidades oferecidas 

• Ter interesse pelas condições de trabalho (local, horários, salário, etc.) 

A experiência profissional do candidato também é de vital importância para o sucesso do projeto. É 
desejável que o candidato tenha trabalhado em diferentes tipos de projeto para ter conseguido 
desenvolver-se e acumular habilidades na prática de gerenciamento de projetos. 



PRINCIPAIS ERROS COMETIDOS NA 
SELEÇÃO DO GERENTE DE PROJETOS 


Todo homem è jruto de suas próprias ideias. ” 


Miguel de Cervantes 

Ainda que os executivos da empresa tenham uma clara descrição do que se espera do gerente de 
projeto, muitas vezes a sua seleção é feita de maneira equivocada, escolhendo-se o profissional 
errado para tal função. A seguir estão alguns critérios comuns segundo os quais a pessoa errada pode 
ser selecionada. 


Maturidade - Muitas vezes a empresa considera maturidade como o tempo de trabalho do candidato, 
idade ou até mesmo sua aparência física. Não é essa a maturidade que se precisa do gerente do 
projeto. O que é necessário é uma maturidade vinda da exposição a vários tipos de projetos em 
várias posições. 

Disponibilidade - A organização não pode selecionar o gerente do projeto somente porque o 
profissional está disponível. É preciso que ele tenha todas as características descritas anteriormente 
e esteja disponível. Outro erro é selecionar o gerente de projeto perfeito, porém completamente 
indisponível, devido a outras atividades na organização. 

Experiência Técnica - Não se pode escolher como gerente de projeto pessoas que têm apenas as 
habilidades técnicas. Certamente elas não conseguem desvincular suas atividades dos aspectos 
técnicos, esquecendo-se dos outros aspectos do gerenciamento de projetos. A seleção de um técnico 
para gerente de projeto somente é aceitável em projetos que requerem, basicamente, experiência 
técnica para seu desenvolvimento, como projetos de pesquisa e desenvolvimento. 

Orientação ao Cliente - Não se pode selecionar o gerente do projeto simplesmente para satisfazer 
um pedido do cliente. Ser capaz de se relacionar com o cliente não é uma garantia de que o projeto 
será bem-sucedido. 

Exposição - O gerente de projeto não deve ser selecionado apenas para ganhar exposição às 
técnicas de gerenciamento de projetos. Primeiro, o gerente de projetos, ao retornar, pode estar 
obsoleto em suas atividades funcionais. Segundo, provavelmente ele não vai querer retornar à 
atividades funcionais após ter trabalhado em projetos. 

Experiência na empresa - Não se pode garantir que um profissional será um grande gerente de 
projeto apenas porque ele já passou por várias áreas da organização. Isso até mesmo pode indicar 
que o candidato não é estável em nenhuma posição da empresa. Se a pessoa não tem competência, 
colocá-la na atividade de gerenciamento de projetos somente irá aumentar o dano causado ao 
negócio. 

Finalmente, é preciso considerar os seguintes fatores: 

• Profissionais não devem ser promovidos a gerentes de projetos apenas porque já atingiram o 
mais alto patamar de salários de sua função. 

• Gerentes de projetos devem ser pagos sobre resultados, não sobre o número de pessoas 
supervisionadas. 



ADMINISTRAÇAO DE CONFLITOS 


E a diferença de opiniões que faz com que existam as corridas de cavalos. ” 

Mark Twain 

O trabalho em gerenciamento de projetos também é caracterizado por conflitos e incertezas. 
Conflitos entre os departamentos funcionais e o time do projeto na concorrência por recursos, 
pessoal e dinheiro e conflitos de interesses entre os envolvidos ( stakeholders ) no projeto. O cliente, 
ao realizar um determinado projeto, deseja mudanças, a organização que executa o projeto deseja 
lucros, que podem ser reduzidos se as mudanças desejadas pelo cliente forem realizadas. O time do 
projeto é, então, dirigido por dois chefes com interesses distintos e muitas vezes opostos. 

Conflitos, se não gerenciados adequadamente, podem ser destrutivos para o projeto. Eles podem 
baixar drasticamente o moral do time e a produtividade, criando tensões entre pessoas, causando a 
formação de mecanismos de competição interna negativos. É importante que o gerente de projeto seja 
capaz de reconhecer as potenciais origens dos conflitos e quando, no ciclo de vida do projeto, esses 
serão benéficos ou maléficos para os trabalhos. 



Figura 4.1 - Nível de Conflitos x desempenho da organização (com base em Robbins e Kotse) 

De acordo como gráfico anterior, pode-se considerar que, em um ponto x, onde o nível de conflito é 
abaixo do esperado, tem-se um desempenho comprometido devido à apatia, à falta de ideias e de 
iniciativa do time e do gerente de projeto. No ponto y, tem-se a melhor relação conflito-desempenho, 
uma vez que eles são funcionais e se relacionam com a criatividade e a iniciativa. O terceiro ponto 
(z) mostra um excesso de conflito, que é negativo para o projeto, uma vez que leva ao caos, à falta de 
cooperação mútua e aos conflitos pessoais. 

Podem ser considerados aspectos positivos do conflito os seguintes: 

• força mudanças; 

• aumenta a criatividade na criação de novas opções; 

• melhora as comunicações se ambas as partes estiverem interessadas em ganhos mútuos; 

• aumenta a energia e a coesão do grupo; 

• promove o balanceamento entre poder e influência, quando associado a técnicas efetivas de 







solução de problemas; 

• clarifica as metas. 

Quanto aos aspectos negativos, podem ser citados os seguintes: 

• aumenta a hostilidade e agressividade; 

• apresenta desejo de ser o vencedor, podendo bloquear a criação de novas alternativas; 

• inibe as comunicações porque a informações relevantes não são compartilhadas; 

• causa estresse e cria uma atmosfera desfavorável; 

• pode, se conduzido da forma ganhador-perdedor, causar perda de status ou posição; 

• apresenta discussões que podem ganhar conotação pessoal. 

Kerzner destaca sete potenciais fontes de conflitos durante o gerenciamento de projetos: 

• conflito de prioridades no projeto; 

• co nfl ito a respeito de procedimentos administrativos; 

• conflitos de opiniões técnicas e de desempenho; 

• conflitos de recursos humanos; 

• co nfl itos sobre custos e orçamentos; 

• conflitos sobre agendamento dos trabalhos; 

• conflitos pessoais. 

Cabe ao gerente de projeto lidar com os conflitos e administrá-los, fazendo com que o projeto se 
beneficie, permanentemente, das discussões e dos diferentes pontos de vista, evitando que os 
conflitos gerem perda de produtividade ou descontrole para o projeto. 



2. ETICA E RESPONSABILIDADE 
PROFISSIONAL 


Um dos aspectos fundamentais do trabalho em projetos está na ética e na responsabilidade 
profissional do gerente de projeto e de sua equipe. Mulcany (2000) afirma que o profissional de 
gerenciamento de projetos tem a responsabilidade de suportar a integridade e a ética da profissão. 
Isso envolve assegurar que todas as ações tomadas estão sempre alinhadas com os requerimentos 
legais e cornos padrões éticos. 

Ao se fazer isso, estará se garantindo a integridade das necessidades dos envolvidos, bem como da 
parte da sociedade que sofre impacto direto pelo projeto. 

Como os projetos envolvem mudanças que afetam tanto a sociedade quanto as empresas, torna-se 
necessário realizar essas mudanças dentro de aspectos éticos e responsáveis. 



1.580 que é Responsabilidade Profissional? 

É o conjunto de ações do gerente de projetos de modo a assegurar uma atitude responsável e ética. 
Essas ações podem ser resumidas nos seguintes itens: 

• faça a coisa correta; 

• siga o processo correto; 

• aja eticamente; 

• reporte qualquer violação; 

• lide cornos problemas; 

• aumente de modo permanente a base de conhecimento e as melhores práticas do projeto; 

• procure os conflitos de interesse e atue em sua solução. 

Muitas vezes os aspectos éticos estão relacionados ao processo cultural de um país ou região e até 
mesmo aos aspectos relacionados ao tipo de educação da pessoa. 

Um exemplo dessa abordagem está no seguinte problema: 

“Quando você checa o calendário do projeto, você observa que uma reunião muito importante com 
um profissional crítico para o projeto foi agendada e você não foi informado. Qual é a MELHOR 
decisão a ser tomada? 

1. Evitar citar o problema para o membro do time e continuar a observá-lo 

2. Notificar seu chefe sobre o problema 

3. Tratar do problema com o membro do time 

4. Tratar do problema com o chefe do membro do time 

Como um profissional com responsabilidade deve olhar de frente o problema e não ter atitudes 
omissas, a decisão mais adequada é tratar do problema com o membro do time. 



1.59Subdivisões da Responsabilidade Profissional 


A responsabilidade profissional se subdivide nos seguintes aspectos: 

• garantir a integridade individual; 

• contribuir para a base de conhecimento em gerenciamento de projetos; 

• aprimorar a competência individual; 

• balancear o interesse dos envolvidos; 

• interagir com o time e os envolvidos de um modo cooperativo e profissional. 

Garantir a Integridade Individual visa garantir a integridade e o profissionalismo através da 
aderência aos requerimentos legais e padrões éticos de modo a proteger a comunidade e todos os 
envolvidos. 

A garantia da integridade individual pode ser evidenciada nos seguintes aspectos: 

• sempre diga a verdade em todos os relatórios, conversações e outras comunicações, mesmo 
que seja solicitado a você que faça o contrário; 

• siga as regras de Copyright e outras leis; 

• nunca divulgue os dados da empresa a pessoas não autorizadas; 

• valorize e proteja a propriedade intelectual; 

• nunca coloque seus interesses pessoais acima dos ganhos do projeto; 

• previna os co nfl itos de interesse e lide com eles quando ocorrerem; 

• não ofereça ou receba suborno ou presentes inadequados; 

• trate todos com respeito; 

• reporte violações às leis, às políticas do negócio, ética e a outras regras; 

• cuidado, não coloque amizade e relações pessoais acima da lei; 

• siga os processos corretos; 

• se, por exemplo, um gerente de projeto não tem autoridade, é requerido pela responsabilidade 
profissional que o gerente de projetos busque essa autoridade; 

• em resumo: faça as coisas certas. 

Contribuir para a Base de Conhecimento em Gerenciamento de Projetos significa compartilhar 
informações aprendidas, melhores práticas, pesquisas, etc., dentro das devidas comunidades, visando 
garantir a melhoria da qualidade dos processos, aprimorando a capacitação dos colegas e da 
profissão. 

A contribuição para a base de conhecimento em gerenciamento de projetos pode ser evidenciada nos 
seguintes aspecto 

• compartilhe as lições aprendidas como projeto com outros gerentes de projeto da empresa; 

• suporte a educação de outros gerentes de projetos e envolvidos sobre gerenciamento de 
projetos; 

• realize pesquisas para descobrir melhores práticas na área e compartilhe-as cornos demais; 

• escreva artigos sobre gerenciamento de projetos; 

• aprimore a competência individual; 



• aprimore a competência individual pela aplicação contínua do conhecimento adquirido para 
melhorar os serviços; 

• trabalhe continuamente para entender suas forças e fraquezas pessoais; 

• continue a aprender; 

• planeje seu desenvolvimento profissional; 

• busque novas informações e práticas que poderão ajudar sua empresa e seus projetos; 

• continue a aprender sobre a área de atuação da empresa. 

Balancear o Interesse das Partes Interessadas significa recomendar estratégias que podem 
relacionar, conciliar e satisfazer diferentes necessidades das partes interessadas. Compreende 
determinar a razão por que o projeto foi iniciado, como as constantes triplas do projeto (PCT) se 
relacionam e se completam. 

O balanceamento do interesse das partes interessadas pode ser evidenciado nos seguintes aspecto: 

• determine e compreenda as necessidades e objetivos de cada um dos envolvidos; 

• procure ativamente por necessidades conflitantes; 

• mantenha o time e os interessados envolvidos e busque a gerência superior quando o time não 
conseguir resolver os conflitos; 

• determine as possíveis soluções para resolver os conflitos; 

• utilize a negociação, a comunicação e o desenvolvimento de times para solucionar interesses 
divergentes; 

• realize reuniões, entrevistas e discussões para resolver os conflitos; 

• busque alternativas quando alguma das técnicas empregadas prejudicarem outros aspectos do 
projeto (Fast Tracking, Crashing); 

• realize mudanças e aprove novamente o Termo de Abertura ou Project Charter se forem 
necessárias para dar um balanceamento ao interesse dos envolvidos. 

Interagir com o Time e os Envolvidos de um Modo Cooperativo e Profissional significa respeitar 
as pessoas, assimilando diferenças culturais, étnicas e sociais de modo a garantir um ambiente 
colaborativo e participativo. 

O relacionamento entre os envolvidos de um modo cooperativo e profissional pode ser evidenciado 
nos seguintes aspectos: 

• respeite as diferenças culturais; 

• diversidade pode tornar o projeto mais rico e divertido; 

• previna o choque cultural através do treinamento e do conhecimento das culturas diferentes; 

• descubra e respeite as diferentes formas de trabalho e comunicação entre os membros do time; 

• utilize uma comunicação clara com a pessoa certa e da forma certa de modo a prevenir que 
diferenças culturais se tornem um problema. 



3. QUESTÕES PARA REVISÃO 


1. O gerente de projetos deve ser necessariamente um técnico? Justifique. 

2. Quais os principais critérios na seleção de um gerente de projetos? 

3. Por que a maturidade pode ser vista de maneira equivocada na seleção do gerente de 
projetos? 

4. Relacione as características do gerente de projetos cornos tipos profissionais requeridos no 
time de projeto em função das fases do projeto (visto no capítulo de gerenciamento de recursos 
humanos). 

5. Até que ponto co nfl itos podem ser benéficos? 

6. Como o gerente de projetos deve explorar os conflitos positivos? 

7. Por que um gerenciamento de conflitos adequado pode forçar mudanças? 

8. Relacione o nível de conflito em cada fase do projeto em casos de projetos bem sucedidos e 
mal sucedidos. 



4. PALAVRA CRUZADA 


Gerente de Projetos e Conflitos 



Horizontais 

1. Aspecto positivo dos conflitos 

4 Pilar do gerente de projetos 

7 Fonte de conflito nos projetos 

8. Tipo de conflito a ser evitado de 
todas as formas em um projeto 

9. Uma habilidade no 
gerenciamento do time do 
gerente de projetos 


Verticais 


2 Erro ao se selecionar 
um gerente de 
projetos 

3. Habilidade do caráter 
do gerente de 
projetos 

5. Uma habilidade de 
comunicação do 
gerente de projetos 

6. Aspecto negativo dos 
conflitos 


Respostas ais porteis no final do Ivro - Anexo II 


















































































































- PARTE VI-0 MODELO GERAL PARA O 
GERENCIAMENTO DE PROJETOS 



1. JUSTIFICATIVA DO MODELO DO 
FLUXO DE ATIVIDADES DO 
PROJETO 

A grande maioria das pessoas que iniciam seus trabalhos com projetos não sabe exatamente que 
passos seguir para planejar, executar e controlar um projeto de maneira eficaz. Muitas dessas 
pessoas não sabem sequer como começar um projeto, perdendo tempo em decorrência da inversão de 
prioridades e sequência. Por isso, este capítulo tem como objetivo descrever, passo a passo, todas as 
etapas necessárias para se implantar um projeto com qualidade. Este modelo foi baseado nas teorias 
propostas no PMBOK, bem como nos comentários de Lewis, Kerzner, Schtub, Galbraith e Sanders, 
mencionados na bibliografia deste livro e, depois, adaptado. O objetivo desta adaptação é adequar o 
modelo geral de gerenciamento de projetos à realidade competitiva brasileira. 



FLUXOGRAMA DO PROJETO 


Para melhor compreender o fluxo de atividades do projeto, tem-se, a seguir, o fluxograma geral do 
desenvolvimento do projeto. O fluxograma proporciona uma visão sequencial de todos os trabalhos a 
serem realizados pelo projeto, incluindo testes, decisões, aprovações e arquivamentos. 

O fluxo foi elaborado para solucionar a grande dificuldade encontrada pelos profissionais ao 
encadear suas atividades e ações dentro de um projeto. 

É importante ressaltar que, mesmo sendo o fluxo um processo sequencial, as fases de planejamento, 
execução e controle são cíclicas até a conclusão do projeto, conforme figura a seguir, discutida no 
capítulo a respeito do ciclo de vida do projeto. 



Figura 2.1 - Inter-relacionamento entre as fases em um projeto (PMI, 2008) - repetição 

Todos os itens do fluxo serão discutidos nos próximos capítulos. Os números entre parênteses em 
cada subtítulo destacam o item representado dentro do fluxo. 




Conjunto maisAdsquado 



Figura 2.2 - O fluxograma geral do projeto (Fase de Iniciação) 












Figura 2.3 - O fluxograma geral do projeto (Fase de Planejamento) 
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Figura 2.4 - O fluxograma geral do projeto (Fases de Execução, Controle e Encerramento) 








FASE DE INICIAÇÃO 



l.óOProblema ou Oportunidade (01) 


Todo projeto tem sua origem em um problema ou uma oportunidade. Pode-se considerar que o não 
aproveitamento de uma oportunidade representa um problema para a organização, uma vez que 
empresas concorrentes, ou até mesmo o mercado consumidor, estão se preparando para se adequarem 
a essas oportunidades. É o marco que determina o início de um projeto. Esse processo consiste em 
desenvolver um conceito para o projeto. É representado por frases do tipo: “Nós necessitamos...”, 
“Seria interessante se...”, “Podemos fazer...”, dentre outras. 

O desenvolvimento formal da oportunidade, ou do obstáculo, deve detalhar o máximo possível toda a 
situação atual da organização, os fatos geradores do problema ou das oportunidades a serem 
aproveitadas. 

Problema é o obstáculo que está entre o local onde se está e o local em que se gostaria de 
estar. 

Diante dessa definição, pode-se ter como metas a serem atingidas por essa formalização as seguintes: 

• identificar e realizar, da melhor forma possível, os esforços necessários para se chegar ao 
outro lado; 

• evitar, de todas as formas possíveis, que o obstáculo aumente ou passe a prejudicar outras 
atividades; 

• saber avaliar corretamente se o que se quer é realmente chegar ao outro lado. 

Muitas vezes essas definições são o problema. Muitos projetos chegam a uma solução correta para 
um problema errado. É importante que se saiba aonde se quer chegar antes de começar a realizar. 

A partir da definição do problema é que se pode determinar as soluções possíveis. Por exemplo: 
“Qual é a melhor maneira de se ganhar dinheiro?” Essa definição de problema é muito geral e 
permite que muitos objetivos específicos possam ser considerados. 

Se se modificar o problema para “Como eu posso ganhar dinheiro comprando e vendendo 
automóveis?”, tem-se um problema muito mais focado e específico. 

Ao se definir o problema, é importante que se saiba qual o seu tipo e características. Existem, 
basicamente, dois tipos de problemas: 

• problemas de Variáveis Abertas; 

• problemas de Variáveis Fechadas. 

Problemas de Variáveis Abertas são problemas que não possuem uma única solução determinada e 
clara. Estão sujeitos a modificações mercadológicas, ambientais e até mesmo a decisões estratégicas 
da empresa. A grande maioria dos problemas que envolvem gerência de projetos são problemas 
abertos. 

Problemas de Variáveis Fechadas possuem apenas uma única solução matematicamente definida. 
Por não sofrerem nenhuma influência do ambiente externo, são de solução e controle aparentemente 
mais fácil. 

Uma situação delicada acontece quando um problema de variáveis abertas é simplificado para um 
problema de variáveis fechadas. Ao se proceder a essa simplificação, deve-se atentar para as 
variáveis que continuarão expostas ao ambiente de mudanças e controlá-las o máximo possível, para 
que os efeitos de uma mudança indesejável possam ser evitados. 




Figura 3.1 - Análise de problemas com variáveis abertas e fechadas 

Todo problema formalmente escrito deve respeitar as seguintes regras: 

• deve ser escrito em pelo menos duas formas diferentes por pessoas diferentes; 

• o ponto principal do problema deve ser destacado isoladamente; 

• a pergunta “O que eu quero realmente fazer é...?” deve ser respondida. 









l.ólCriar o Termo de Abertura ou Project Charter (02) 


Após definida a necessidade de se estabelecer um projeto, deve ser criado o Termo de Abertura ou 
Project Charter. Como já visto, o Project Charter é o documento legal que reconhece a existência de 
um projeto. Ele serve como uma linha de base para o trabalho do gerente do projeto. Contém 
diversas informações sobre o projeto, incluindo estimativas iniciais de qual o prazo destinado, os 
recursos necessários e o orçamento disponível. Todos esses dados são preliminares e, normalmente, 
realizados pelos executivos da empresa, identificando suas necessidades e interesses. 

Podem se considerar como elementos do Project Charter: 

• título do projeto; 

• um resumo das condições que definem o projeto (introdução); 

• nome do gerente de projeto e suas responsabilidades e autoridades; 

• necessidades básicas do trabalho a ser realizado; 

• descrição do produto do projeto; 

• cronograma básico do projeto; 

• estimativas iniciais de custo; 

• necessidades iniciais de recursos; 

• necessidade de suporte pela organização; 

• controle e gerenciamento das informações do projeto; 

• aprovações com assinatura do executivo responsável pelo documento (elemento externo ao 
projeto). 

Como já visto, esse processo é integrante dos processos de gerenciamento da integração. 



1.62Identifícar e Selecionar o Gerente de Projeto (03) 


Essa etapa é a responsável pela identificação e seleção do gerente de projeto. A partir desse ponto, o 
gerente de projeto é o condutor central dos processos seguintes. Maiores detalhes podem ser vistos 
na Parte V do livro - O Gerente de Projeto e Suas Interfaces. 



1.63Criar o Livro Geral do Projeto (04) 


É importante que todas as informações do projeto sejam documentadas. A documentação tem três 
objetivos básicos: 

• Registrar, formalmente, as decisões e aprovações dos envolvidos (assinaturas, observações, 
etc.); 

• facilitar a revisão da estrutura do projeto; 

• servir de base para futuros projetos da empresa (aprendizado). 

O livro geral do projeto, ou Project Databook , é um documento que registra todos os fatos 
acontecidos no projeto, desde a fase de definição até a fase de finalização. 

No caso de livros do tipo “papel”, ele deve possuir as seguintes características: 

• todas as páginas devem ser numeradas e rubricadas pelo responsável pelo livro; 

• o termo de abertura do livro deve conter os nomes das pessoas que terão acesso direto a ele, 
bem como a relação de todas as pessoas que poderão representar diretamente os envolvidos 
(cliente, os fornecedores e a equipe do projeto); 

• nenhuma página do livro deve ser removida, retirada do conjunto ou substituída; 

• todas as decisões tomadas pelo projeto devem ser registradas imediatamente no livro e 
autorizadas por escrito pelos envolvidos; 

• o fechamento do livro geral do projeto, com a rubrica de todos os envolvidos com o projeto 
(clientes, fornecedores, etc.), deverá ser feito quando as páginas do livro estiverem esgotadas, 
ou o projeto tiver sido concluído; 

• no caso de projetos grandes, devem ser criados vários livros de projeto; esses livros devem 
ser numerados sequencialmente e fechados um a um, logo após seu término; 

• não se devem utilizar dois livros de projeto simultaneamente, para que os dados fiquem 
centralizados em um único documento. 

Atualmente é muito comum confeccionar o livro através do computador. Nesse caso, diversos 
softwares de gestão eletrônica de documentos (GED) podem ser utilizados, desde que garantam 
as características de armazenamento e segurança. 

O Gerenciamento Eletrônico de Documentos converte informações de texto, voz e imagens para a 
forma digital. Funciona com softwares e hardwares específicos e utiliza as mídias ópticas, em geral, 
para armazenamento. 

Um sistema de GED usa a tecnologia da informática para captar, armazenar, localizar e gerenciar 
versões digitais das informações, dentre elas: 

Voz - Informações geradas de forma verbal, tais como atas de reunião, aprovações verbais, etc. 

Texto - Informações normalmente mais formais. Vão de cartas a contratos, planilhas, manuais, etc. 

Imagem - Informações que não podem ser representadas nas formas anteriores: mapas, fotografias, 
assinaturas, etc. 




Figura 3.2 - Exemplo GED da solução de Enterprise Project Management da Microsoft através do Microsoft Project Web 
Access 


O livro geral do projeto não é apenas um documento que formaliza e registrador de fatos. Ele é uma 
fonte de consultas sobre o projeto e, portanto, todas as considerações, discussões e conclusões 
devem estar registradas, mesmo que se venha a concluir, posteriormente, que a consideração feita era 
incompleta, ou absolutamente errada. Nesse caso, o registro dessas falhas servirá de base para que, 
em futuros projetos, essas falhas não voltem a ocorrer. 

Lembre-se: gerenciamento de projetos não é matemática e, na maioria das vezes, subestimar uma 
alternativa ou consideração, por mais absurda que pareça à primeira vista, pode representar o 
fracasso do projeto. 





















1.64Defínir o Objetivo, a Justificativa, o Produto e as Entregas do 
Projeto (05) 


Todo projeto necessita de um objetivo e uma justificativa clara e tangível, bem como seus produtos e 
entregas devem ser bem definidos. O objetivo destaca aquilo que se quer atingir com o término do 
projeto. A justificativa é o objetivo implícito no projeto, a razão de ser de todo o projeto. Os 
produtos são os bens, ou resultados, que se espera colher ao término do projeto. As entregas são os 
resultados físicos atingidos ao longo do projeto que asseguram que os produtos serão obtidos de 
maneira satisfatória. 

Objetivo é a representação formal daquilo que se quer atingir com o término de um projeto. 

r 

E facilmente mensurável e controlável. Normalmente é definido por verbos de ação. 
Parâmetros numéricos de tempo, custo e desempenho devem estar descritos no objetivo. 

Exemplo: Implementar o gerenciamento de projetos na divisão dentro das metodologias 
estabelecidas pela divisão de projetos corporativos da matriz (USA), dentro de um prazo 
máximo de 180 dias corridos a partir de janeiro de 2004 e com um custo total estimado de 
$1.000.000 (custo adicional) 

Justificativa é tudo aquilo que está oculto no objetivo, isto é, é a razão de ser do projeto, o 
benefício gerado por ele. E de difícil mensuração porque representa, na maioria das vezes, 
um sentimento da organização. Também conhecido como missão. 

Exemplo: Preparar a divisão para um aumento significativo na demanda por serviços 
decorrentes de um aumento nas linhas de produtos oferecidos pela companhia e de 
movimentos de concorrentes. 

É importante ressaltar que o objetivo e a justificativa sempre se completam. Isso significa que o 
objetivo, sozinho, não define o projeto. É preciso que ele esteja associado a uma determinada 
justificativa ou razão. Por outro lado, uma determinada necessidade ou justificativa também pode 
caracterizar inúmeros objetivos. 



Figura 3.3 - Relacionamento entre objetivo e justificativa para um escopo definido 

A seguir, são dados dois exemplos que caracterizam a consistência entre objetivo e justificativa, para 














um escopo definido. 

Exemplo 01 

Objetivo - Concluir o curso de Administração (Empresas) em uma universidade pública no limite 
máximo de quatro anos. 

Justificativas possíveis para esse objetivo 

• Realização pessoal 

• Consecução de uma estabilidade financeira e possibilidade de ascensão profissional 

• Simpatia pelo assunto 

• Conhecimento de pessoas 

• Status e reconhecimento 

• Sequência da carreira dos pais ou pessoas de influência pessoal 

Observa-se, nessas missões, que um único objetivo é capaz de ter implícitas inúmeras delas. 

Exemplo 02 

Necessidade: Consecução de estabilidade financeira e possibilidade de ascensão profissional. 
Objetivos possíveis para essa necessidade (justificativa) 

• Montar um restaurante à beira-mar e vender bebidas e comidas típicas da região. 

• Concluir o curso de administração de empresas em uma universidade pública no limite 
máximo de quatro anos. 

• Fazer um MBA no exterior e retornar ao Brasil como mestre em administração de negócios. 
Observa-se que uma única necessidade pode-se traduzir em diferentes objetivos. 

Produtos são todos os resultados físicos obtidos na conclusão do projeto. Os produtos 
identificam a abrangência do projeto. 

Exemplo: Metodologia implementada e documentada com aprovação do patrocinador, bem 
como um projeto-piloto implementado na divisão para avaliar a efetividade da metodologia. 
Exemplo: O produto de um curso superior é o diploma de fim de curso. 

Entregas são todos os resultados físicos ou semiprodutos obtidos ao longo do projeto. 
Servem para medir e avaliar o desempenho do projeto. Normalmente podem ser definidas 
através de marcos ou etapas no cronograma. 

Exemplo: O projeto da implementação do gerenciamento de projetos em uma empresa pode 
ter uma entrega chamada “Diagnóstico concluído ”, outra chamada “Treinamento realizado ”, 
outra chamada “Software instalado ”. Ambas são entregas de um único projeto e servem para 
identificar o que foi e o que não foi concluído. 

Exemplo: O histórico escolar é um relatório com as entregas concluídas em um curso 
superior. 



1.65Arquivar Informações no Livro Geral do Projeto (06) 


Após terem sido definidos os objetivos, a justificativa, os produtos e as entregas do projeto, essas 
definições devem ser arquivadas ou gravadas no Livro Geral do Projeto, juntamente com o Termo de 
Abertura (Project Charter ), para posterior acompanhamento. 



1.66Criar Alternativas de Condução do Projeto para Construção 
do Escopo (07) 


Esta etapa é a responsável pela criação de alternativas (formas) de se conduzir o projeto. Seu 
objetivo é descrever como serão realizados os trabalhos durante o projeto de modo a facilitar a 
construção do escopo do projeto. Usualmente o PMBOK Guide se refere a esse processo como 
“Coleta de Requisitos”. 

As alternativas geradas devem ser capazes de responder à seguinte questão: 

Como nós iremos fazer isso? 

Diversos fatores devem ser considerados ao se criarem alternativas, uma vez que diversos elementos 
do ambiente ou da empresa podem favorecer ou não determinadas estratégias: 

Fatores ambientais 

• tecnologia 

• economia 

• governo 

• localização geográfica 

• sociedade 

Fatores Organizacionais 

• experiência dos profissionais 

• relações de trabalho 

• disponibilidade física de recursos 

• experiência no tipo de projeto a ser desenvolvido 

• imagem da empresa 

• atitude da alta gerência 

• moral dos empregados 

• posicionamento do marketing 

• comprometimento da organização como projeto 

• expectativas dos envolvidos 

A expectativa da alta gerência, normalmente, é a maior influenciadora do sucesso ou do fracasso do 
projeto. Quando essas expectativas, ou previsões, para o desempenho do projeto são irreais, o 
impacto é quase sempre negativo. 

A criação dessas alternativas deve ser realizada no tempo certo. As alternativas desenvolvidas 
precocemente são vagas e imprecisas, já que não se conhece praticamente nada do projeto. Quando o 
desenvolvimento das alternativas é feito tardiamente, as decisões normalmente já foram tomadas, 
limitando muito as alternativas viáveis e gerando um custo elevadíssimo de implementação, como foi 
visto nos capítulos anteriores. 

A maioria das alternativas de condução é criada através de reuniões de Brainstorming, onde cada 
pessoa sugere alternativas para cada fase, ou etapa, do problema definido, sem que haja 
discriminações ou críticas por parte dos outros envolvidos. Esse processo é conhecido como 



Estratificação. 

Por exemplo, em uma implementação de um escritório de projetos (PMO), diversos assuntos 
precisam ser abordados, tais como o software, o hardware, o padrão a ser usado, o treinamento, 
dentre outros. 

No caso do treinamento básico, pode-se determinar através de Brainstorming a maior quantidade 
possível de alternativas para cada categoria destacada, como é apresentado no mapa a seguir. 


Software 



Figura 3.4 - Exemplo de mapa mental para a criação de alternativas (Mapa mental) 

Pode-se observar que todas as alternativas, por mais absurdas que pareçam, foram colocadas no 
plano para serem avaliadas posteriormente. 

























1.67Estimar Desempenho, Custo, Tempo, Riscos, Consequências e 
Cultura das Alternativas (08) 

Para cada alternativa gerada em cada categoria, deve-se estimar sua qualidade (desempenho), seu 
custo, seu tempo de execução e sua capacidade de atender ao escopo definido para o projeto. Os 
valores gerados nessa fase devem ser os mais precisos possíveis, sem que se perca muito tempo em 
análises e discussões. Afinal, eles são somente estimativas. As estimativas, por serem empíricas, 
devem ser estimadas através de notas (0 a 10). Quanto mais próxima de dez for a nota, mais aquela 
alternativa atenderá ao que foi estabelecido no objetivo. Ou seja, se uma alternativa recebe uma 
nota alta para o risco, isso significa que o nível de risco da alternativa é pequeno . Uma nota 
baixa para o risco representa um risco elevado, uma vez que os riscos não estão atendendo ao 
que foi estabelecido na definição dos objetivos. Os parâmetros devem ser calculados através de 
histórico, simulação ou estatísticas. Todas as alternativas deverão ser mantidas no processo de 
análise, mesmo que elas apresentem valores absurdos, se comparados com os valores estabelecidos 
para o projeto. A análise de cada alternativa e a escolha da mais adequada será realizada 
posteriormente. 

Os fatores de análise estão descritos a seguir: 

Desempenho (P) - Representa a qualidade intrínseca daquela alternativa dentro do projeto. Quanto 
mais qualidade tem a alternativa, maior será sua nota. A abreviação “P” foi mantida pela 
popularidade do termo Performance. 

Custos (C) - Representa o custo de se optar pela alternativa. Na atual conjuntura dos projetos, 
quanto menor o custo, maior será a nota. 

Tempo (T) - Representa o período de tempo gasto para executar a alternativa. Na atual conjuntura 
dos projetos, quanto menor o prazo, maior será a nota (tempo é sempre um fator crítico). 

Riscos (R) - representa um perigo, ou possibilidade de perigo, que pode ser gerado pela alternativa 
durante sua implantação. O projeto corre risco enquanto está sendo realizado, nunca após seu 
término. Riscos podem ser previsíveis, ou não. No caso de riscos não previsíveis, como desastres 
aéreos, desabamentos ou enchentes, deve-se trabalhar com a distribuição probabilística para que se 
faça a estimativa. 

Consequência (CO) - São os fatos negativos, ou positivos, que o projeto pode gerar após sua 
conclusão, tais como demissões, oportunidades de vendas de produtos agregados, impactos 
ambientais, retaliações por parte de fornecedores, clientes e outros envolvidos. 

Adequação à Cultura (AC) - Significa verificar se a alternativa está dentro do contexto cultural 
vigente na organização e no mercado. Alternativas que propõem um choque cultural na empresa, ou 
no mercado, devem merecer atenção especial em sua análise. 



1.68Arquivar Alternativas com Estimativas no Livro Geral do 
Projeto (09) 


Todas as alternativas devem ser arquivadas com suas respectivas estimativas. O arquivamento é 
realizado através de tabelas para cada alternativa em cada categoria. 

Uma sugestão de tabela para cada alternativa é mostrada na figura a seguir. 


Categoria - 

Alternativa - 

Detalhamento da Alternativa - 

Fator 

Nota 

Justificativa 

Desempenho 



Custo 



Tempo 



Riscos 



Consequência 



Cultura 



Outros (se necessário) 




Figura 3.5-Tabela de arquivamento de alternativas e respectivas estimativas para o projeto 

Como exemplo, tem-se, na figura a seguir, a tabela de arquivamento das alternativas “Treinamento 
realizado externamente” para a categoria “Treinamento básico”. Os valores e as notas apresentadas 
são meramente ilustrativos. 


Categoria - Treinamento Básico 


Alternativa - Treinamento realizado externamente 

Detalhamento da Alternativa - Realizar o treinamento básico de todos os alunos previstos fora 

das instalações da empresa, com 
especializados no assunto 

instrutores, material didático e infra-estrutura de terceiros 

F3tor 

Nota 

Justificativa 

Desempenho 

8 

tors o d es envovi aopotproíssionaôda area 

Custo 

5 

Invesiimènioêlévããõ 

Tempo 

6 

O deslocamento dos slunos até a empresa pode ser um fator de impedimento 

Riscos 

9 

A empresa ja possui expenênaa comprovada no as surto 

Consequência 

8 

Ô curso senoo reaiiíado tora possiWKa uma maior concentração dos alunos no 

curso o que favorece os resultados 

Cultura 

10 

E perfeitarnente normal contratar-se treinamento externo no Brasil 


Figura 3.6 - Exemplo para a alternativa “Treinamento realizado externamente” 



























1.69Selecionar o Melhor Conjunto de Alternativas para o Projeto 

( 10 ) 


A seleção da alternativa mais adequada para se conduzir o projeto é feita através de comparação 
direta entre as alternativas disponíveis. Todas as estimativas realizadas para cada alternativa serão 
comparadas nessa fase, tais como 

• desempenho; • riscos; 

• custo; • consequências; 

• tempo; • cultura e outros 

Diversos mecanismos podem ser utilizados na seleção da alternativa 11 , mas os mais comuns são os 
modelos de pontuação e ponderação. Os modelos de pontuação e ponderação consistem em atribuir 
notas de 0 a 10 para cada alternativa em cada fator analisado. Todos os fatores recebem um peso 
relativo à sua importância para o projeto, normalmente variável de 1 a 3. O total de pontos é 
calculado através de média ponderada de cada nota ao peso relativo do fator, ou seja, 

TotaiFaiac 

V XotaxPesoFator 

TOíüi — TfHTHriE 

V Peso Fator 
u 

Onde TotalFatores = n° total de fatores analisados. 


Lembre-se! Quanto maior a nota, mais efeito positivo a alternativa tem para o projeto. Por exemplo, 
uma nota alta para o fator risco representa um risco baixo (efeito positivo). 


CATEGORIA DE ALTERNATIVAS 1 


Desemp. 

Custo 

Tempo 

Riscos 

Conseq. 

Cultura 

Total 

Peso 

2 

3 

2 

3 

2 

1 

Altern. 1 

5 

7 

2 

4 

9 

4 

5,31 

Altern. 2 

8 

9 

7 

6 

10 

10 

8.74 

Altern. 3 

1 

3 

2 

3 

5 

3 

2,94 

Altern. 4 

6 

7 

8 

4 

3 

2 

4.47 


Figura 3.7 - Modelo de Pontuação e Ponderação Padrão 

Para a tabela anterior, pode-se interpretar a fórmula dada para o cálculo da nota total da alternativa 
como 


NotaDesemp enhox2 + NotaCustox 3 + 

Nota - NotaTem P ox 2 ~ NotaRiscox 3 -NotaConseq üênciax2 - NotaCulturaxl 


Para a alternativa 1, tem-se 


Kl . 5x2 + 7x3->-2x2 + 4x3^9x2 + 4x1 ... 

Nota =-= o,31 
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Analogamente, para as demais alternativas, tem-se 
• alternativa 2 Nota 8,74 em 10 pontos; 




















• alternativa 3 Nota 2,94 em 10 pontos; 

• alternativa 4 Nota 4,47 em 10 pontos. 

Portanto, a alternativa 2 é a que apresenta maior nota e, consequentemente, maior possibilidade de 
atender melhor aos fatores colocados. 

O modelo de pontuação e ponderação tem como objetivo apoiar a escolha da alternativa, porém não 
deve ser utilizado como a única forma de selecionar alternativas. Algumas vezes, escolhem-se 
alternativas com menos pontuação, mas que, diante do consenso do grupo, apresentam maior 
facilidade de execução. 

Essa tabela é construída para cada categoria a ser analisada, escolhendo-se a melhor em cada uma 
delas. O conjunto final de alternativas do projeto é a soma de todas as alternativas vencedoras. Uma 
única precaução precisa ser tomada no que diz respeito à coerência e à sinergia entre as alternativas. 
Pode acontecer que a escolha de uma alternativa em uma categoria entre em contradição com a 
melhor alternativa em outra categoria. Por exemplo: se a opção de software escolhida para o 
escritório de projetos for uma solução baseada em um computador de tecnologia Risc, não será 
possível escolher no hardware um computador com tecnologia Intel, uma vez que o programa 
escolhido não funciona em máquinas Intel, por exemplo. 

Como exemplo de conjunto de alternativas, tem-se, para o projeto de implementação do escritório de 
projetos. 

1. Geral 

o O custo de pessoal interno não está incluído no valor anterior e não será considerado por já fazer parte do custo 
indireto da empresa. 

o Serão consideradas críticas as atividades com folga menor ou igual a 3 dias. 

2. Diagnóstico 

o Realizado pela divisão de gerenciamento de projetos da matriz (USA), com custos arcados pela divisão, tais como 
deslocamentos, traslados, hospedagem, etc. 
o É acompanhado por consultor especializado externo. 

3. Treinamento 

o Prevê treinamento de software e metodologia de gerenciamento de projetos, integralmente terceirizado para a empresa 
GP Projetos, inclusive para os usuários finais. 

o Prevê treinamentos básicos (150 participantes) e avançados (30 participantes) sobre gerenciamento de projetos, além 
do treinamento para a equipe de suporte (30 participantes), 
o Inclui palestra para diretoria e alta gerência. 

o As máquinas utilizadas no treinamento já serão as definitivas dos usuários, 
o O treinamento será em horário integral e com todas as turmas sequenciadas. 
o O treinamento terá preço fechado por turma (30 alunos cada). 

4. Software 

o Microsoft Project 2002 com Microsoft Project Web Access para todas as máquinas, 
o Software de Gestão Eletrônica de Documentos no servidor 
o SQL Server 2000 como plataforma de banco de dados no servidor 

o Windows.net (server) e Windows XP Professionalpara servidores e usuários, respectivamente, 
o Instalação realizada pelo departamento de informática, 
o Produtos precisam ser adquiridos, 
o Programa para GED precisa ser avaliado e adquirido. 

5. Hardware 

o 2 Servidores IBM adquiridos diretamente da IBM (incluindo Backup). 

o 165 Microcomputadores Dell Pentium IV I,4GHz com 512MB de Memória RAM, HD de 40 GB e rede (15 
computadores de Backup). 

o Instalação realizada pelo departamento de informática da companhia. 

o Inexistência de outros equipamentos disponíveis devido ao deslocamento dos atuais para outros setores. 

6. Piloto 

o Lançamento de campanha publicitária. 



o Duração máxima de 15 dias de execução. 

o Realizado por empresa especializada (GP Projetos) em parceria com a divisão, 
o A avaliação de resultados deve incluir o patrocinador: 

7. Padronização 

o Inclusão de padronização de projetos, relatórios, modos de exibição, estrutura de GED através do site 
www. ricardovargas. com. br/fronteiras, 
o Realização externa (GP Projetos) com apoio da divisão, 
o Confecção dos padrões realizada internamente pela empresa, 
o Padrão aprovado pelo gerente de projeto. 

Observa-se que esse conjunto de alternativas basicamente estrutura o escopo do projeto e serve de 
base para a criação da Declaração de Escopo (Scope Statement). 



1.70Descartar e Arquivar para Futuros Projetos (11) 


Todas as alternativas que participaram da seleção e não foram selecionadas devem ser descartadas 
do projeto e arquivadas para futuros projetos. A razão para o arquivamento dessas alternativas está 
no fato de que, se, no decorrer da execução do projeto, acontecer alguma falha grave na alternativa 
anteriormente escolhida, mantêm-se disponíveis alternativas de condução já criadas e analisadas. 



1.71Criar a Declaração de Escopo do Projeto ou Scope Statement 

( 12 ) 


Essa etapa tem como objetivo criar a Declaração de Escopo. Como foi visto no capítulo de 
gerenciamento de escopo, o scope statement é o documento que formaliza o escopo de todos os 
trabalhos a serem desenvolvidos no projeto, servindo de base para futuras decisões do projeto. É 
possível que, ao longo dele, a declaração de escopo seja revisada, ou refinada, para refletir as 
mudanças acontecidas no projeto. 

Normalmente, a Declaração de Escopo contém: 

• título do projeto; 

• nome da pessoa que elaborou o documento; 

• nome do patrocinador; 

• nome do gerente do projeto e suas responsabilidades e autoridades; 

• nome dos integrantes do time do projeto; 

• descrição do projeto; 

• objetivo do projeto; 

• justificativa do projeto; 

• produto do projeto; 

• expectativa do cliente/patrocinador; 

• fatores de sucesso do projeto; 

• restrições; 

• premissas; 

• exclusões específicas (tudo o que não será abordado pelo projeto); 

• principais atividades e estratégias do projeto; 

• principais entregas do projeto; 

• orçamento básico do projeto; 

• plano de entregas e marcos do projeto; 

• registro de alterações no documento; 

• aprovações. 



1.72Aprovar a Declaração de Escopo (13) 


A Declaração de Escopo deve ser, formalmente, aprovada por todos os envolvidos e interessados de 
maneira formal, normalmente através de assinatura no livro geral do projeto. Essa aprovação tem 
como objetivo evitar posteriores reclamações, que poderíam ter sido evitadas com essa 
formalização. Normalmente, a aprovação da declaração de escopo também representa a liberação da 
maior parte da verba disponível para o projeto. 

No caso de não aprovação da declaração de escopo, é preciso que o projeto seja revisto, caso essa 
ação seja possível. Caso contrário, o projeto pode ser abortado (passo 13A - Rever viabilidade do 
projeto ou abortar projeto). 



FASE DE PLANEJAMENTO 



1.73DefInir e Agrupar os Pacotes de Trabalho e as Entregas do 
Projeto (WBS) (14) 


Nessa etapa, todos os pacotes de trabalho e suas entregas devem ser identificados e agrupados, 
constituindo um todo organizado. A maioria das entregas principais está definida no Project Charter 
e são as entregas das fases ou atividades de resumo do projeto. 

Pacote de Trabalho é o produto a ser entregue no mais baixo nível da estrutura analítica do 
projeto (WBS). Um pacote de trabalho pode ser repartido em atividades. Também podem 
ser denominadas atividades de resumo. 


Entregas são todos os resultados físicos, ou semiprodutos, obtidos ao longo do projeto. 
Servem para medir e avaliar o desempenho do projeto. Normalmente, podem ser definidas 
através de marcos, ou etapas no cronograma. 

Os pacotes de trabalho são estruturados de modo a compor o Work Breakdown Structure, ou WBS. O 
WBS, também conhecido como Estrutura Analítica do Projeto (EAP). 

A EAP é a ferramenta de gerenciamento do escopo do projeto. Cada nível descendente do projeto 
representa um aumento no nível de detalhamento do projeto, como se fosse um organograma. O 
detalhamento pode ser realizado até o nível desejado, apresentando dados genéricos ou detalhados. 
O detalhamento mais usual é até o pacote de trabalho ( workpackage) 


PROJt IO NOVAS 
FROHTIWAS 



Figura 4.1 - Exemplo de EAP 

São características da EAP as seguintes: 

• permite que se veja a contribuição dos pacotes de trabalho (work package) no projeto 
principal; 






• permite o direcionamento das equipes, dos recursos e das responsabilidades; 

• determina quais materiais serão necessários para a execução de cada pacote; 

• determina o custo final do projeto a partir do custo de cada pacote ou entrega. 

Suas principais vantagens são as seguintes: 

• conjuntos de entregas agrupadas de forma simples; 

• fácil atribuição de responsabilidades; 

• fácil desmembramento do projeto empacotes de trabalho (work package). 

Suas principais desvantagens são as seguintes: 

• não diferencia, visualmente, o prazo e a duração de cada pacote, bem como a importância de 
cada um; 

• não mostra as interdependências entre as entregas e os pacotes; 

• requer técnica e habilidade para confecção e não é construída graficamente pelo Microsoft 
Office Project, sendo necessária a utilização do Microsoft Office Visio ou do WBS Chart Pro 
(www.criticaltools.com). 

O descritivo de cada pacote de trabalho compõe o Dicionário da WBS. Nele estão contidos os 
seguintes elementos: 

• descrição detalhada do trabalho a ser realizado; 

• lista de premissas para a realização do pacote; 

• lista de recursos para a realização do trabalho; 

• pacotes predecessores e sucessores. 

É importante ressaltar que, apesar do nome conter a palavra dicionário, o Dicionário da WBS não é 
um livro de termos e definições. 

A EAP pode ser detalhada na medida da necessidade do projeto. Projetos muito complexos exigem 
um detalhamento elevado para um melhor acompanhamento. Projetos mais simples não necessitam de 
detalhamentos significativos. Os níveis mais comuns de detalhamento do projeto são mostrados na 
figura a seguir. 
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Figura 4.2 - Nomes e detalhamento para as estruturas do WBS 

Existem duas formas de estruturação das atividades para compor a EAP, a saber: 

• técnica Top-to-Bottom ou Decomposição; 

• técnica Bottom-Up. 







































Técnica Top-to-Bottom ou Decomposição 

É a forma mais fácil de criar e detalhar as entregas necessárias. Sua estrutura deve ser criada de 
cima para baixo, isto é, das macrofases do projeto até os níveis de esforço (entregas estritamente 
operacionais). Sua construção segue os seguintes passos: 

1. identificam-se as grandes fases do projeto; 

2. para cada fase identificada, detalham-se as entregas desejadas; 

3. para cada entrega, detalha-se o pacote de trabalho necessário para a sua conclusão; 

4. se necessário, para cada pacote de trabalho, detalha-se o nível de esforço localizado para a 
conclusão do respectivo pacote; 

5. agregam-se os conjuntos de modo a produzir a EAP. 

Técnica Bottom-Up 

Exige maior técnica do gerente de projeto. Sua estrutura deve ser criada de baixo para cima, isto é, a 
partir de um conjunto aleatório de entregas, gerado através de brainstorming ou da experiência dos 
participantes. Procuram se agrupar os pacotes de trabalho de modo a criar entregas. As entregas são 
agrupadas em fases, e as fases, no projeto. Deve ser utilizado para corrigir projetos já iniciados 
incorretamente. Sua construção segue os seguintes passos: 

1. obtém-se o conjunto de entregas através de brainstorming , ou através da experiência dos 
envolvidos; 


2. criam-se os pacotes de trabalho para atingir as entregas; 

3. agrupam-se as entregas em fases; 

4. agrupam-se as fases em um projeto. 



12 


Figura 4.3 - Técnica Top-to-Bottom x Bottom-Up 














1.74Criar Planos de Gerenciamento de Escopo, Qualidade e 
Comunicações (15,16 e 17) 


Logo no início do planejamento, é importante que os planos de gerenciamento de escopo, qualidade e 
comunicações sejam desenvolvidos, uma vez que a maior parte das informações necessárias para 
esses planos já está disponível, e eles serão de extremo valor para a construção do plano do projeto. 
Conforme já visto, esses planos têm como objetivo administrar e controlar determinadas áreas do 
projeto de maneira formal, descrevendo os procedimentos que serão utilizados para gerenciar todo o 
escopo, a qualidade e as comunicações. 

Maiores detalhes sobre os planos podem ser encontrados nos capítulos das áreas do gerenciamento 
de projetos. 



1.75Criar a Lista de Atividades para os Elementos do WBS (18) 


Após definida a EAP, é importante que todos os pacotes de trabalho sejam estratificados em suas 
atividades ou tarefas (nível de esforço). 

Atividades são as etapas necessárias para se completar um projeto. São executadas em uma 
sequência caracterizada pela natureza do projeto. As atividades podem ocorrer 
sequencialmente ou simultaneamente. 

Muitas vezes essa etapa é feita concomitantemente com as definições dos pacotes de trabalho (etapa 
anterior). A maioria dos programas de computador destinada a esse fim trata os dois processos como 
um só, a serem realizados em conjunto, ou seja, o projeto vai sendo decomposto até que todas as 
etapas e entregas sejam atingidas. 

Os principais tipos de atividades são: 

• atividades executivas ou tarefas ( Tasks ); 

• marcos ou entregas ( Milestones ); 

• atividades-resumo ou pacotes de trabalho ( Summary Tasks). 

1.75.1 Atividades Executivas ou Tarefas 

São as atividades relacionadas diretamente coma ação dentro do projeto. 

Exemplos de atividades executivas: 

• embalar computadores; 

• limpar o terreno; 

• digitar o relatório de compras; 

• revisar um artigo. 

1.75.2Marcos ou Entregas (Milestones) 

O marco representa um evento, ou condição, que marca a execução de um grupo de atividades 
relacionadas entre si, ou o término de uma fase de projeto. Servem, também, para identificar as 
entregas dos pacotes de trabalho e não possuem duração. É também chamado de etapas. 

Exemplos de marcos: 

• telhado pronto (entrega); 

• testes do produto realizados; 

• recebimento da 3 a parcela. 

1.75.3 Atividades-Resumo ou Pacote de Trabalho (Summary Tasks) 

São atividades que englobam outras atividades, denominadas subatividades. Elas representam um 
conjunto de atividades, totalizando duração, datas e custos das atividades a elas pertencentes. As 
atividades de resumo também podem ser chamadas de pacotes de trabalho. 

Exemplos: 



• fase de planejamento; 

• construção do alicerce da casa; 

• desenho do protótipo do produto; 

• fase de Design. 

A decomposição do pacote de trabalho em atividades e entregas pode ser visualizada na figura a 
seguir. 



PacofedeTrabaiho 


E ntrega ou Marco 


Tempo 


Figura 4.4 - Decomposição do Pacote de Trabalho em atividades e entregas 






1.76Determinar a Duração das Atividades do Projeto (19) 


Essa etapa tem por objetivo calcular ou determinar, corretamente, a quantidade de tempo necessária 
para executar cada atividade para que, ao ser integrante de um cronograma, possa determinar a 
duração do projeto. Essa etapa é conduzida em paralelo à alocação de recursos nas atividades, uma 
vez que existe uma dependência intrínseca entre duração e quantidade de recursos. 

A duração de uma atividade é o tempo necessário para que a atividade possa ser realizada. 
Pode ocorrer em semanas, dias, horas e minutos, dependendo de cada projeto. 

Para se calcular a duração do projeto, é necessário que se conheçam todos os recursos alocados na 
atividade e a produtividade de cada um deles. 

Segundo Lewis, estima-se que, em um projeto, o tempo perdido em atividades não ligadas a ele é de 
40% do tempo total. Esse conceito é denominado Fator de Produtividade. Não se deve ser surpreso 
quando, ao alocar um recurso em um projeto com horário integral (full time), perceber que, na 
verdade, o recurso trabalhará apenas quatro ou cinco horas por dia. O uso do fator de produtividade 
no cálculo do tempo necessário para o recurso completar a atividade torna a estimativa mais realista. 

1.76.1 Atividades com Duração Fixa x Atividades Orientadas para Recursos 

Ao alocar um recurso em uma atividade, deve-se avaliar se o recurso influencia, de maneira direta 
ou não, a duração da atividade. Se um recurso não influencia a duração de uma atividade, essa 
atividade é denominada de duração fixa (fixed duration). Se um recurso influencia a duração de uma 
atividade, essa atividade é denominada de orientada para recurso {resource driven). As atividades 
que são orientadas para recursos reduzem sua duração com o acréscimo na quantidade de recursos, 
isto e, 

^ na quantidade de recursos 4» na duração da atividade 



Figura 4.5 - Atividades com duração fixa e orientada para recursos 

Observa-se, pela figura anterior, que atividades com duração fixa não são beneficiadas por 
acréscimos na quantidade de recursos. Já atividades com duração orientada para recursos são muito 
beneficiadas por um aumento na quantidade de recursos. 

A orientação para recursos tem um limite de validade lógico, de forma que, depois de passado esse 









limite, um aumento de recursos não provoca redução na duração da atividade e, em casos extremos, 
pode até aumentar a duração da atividade. Por exemplo, se um pedreiro constrói uma parede em 4 
dias, é de esperar que 2 pedreiros a construirão em 2 dias. Porém, é absurdo considerar que 5000 
pedreiros construirão a parede em 23 segundos. 

O quadro a seguir compara durações fixas e orientadas para recursos. 


Figura 4.6 - Exemplo de comportamento fixo e orientado para recursos para as atividades 

O ato de aumentar a quantidade de recursos a fim de reduzir a duração de uma atividade é 
denominado Compressão ou Crashing e constitui uma das formas mais populares de compressão de 
duração de atividades. 

1.76.2Análise PERT 

Outro processo fundamental no cálculo da duração das atividades é a análise PERT, onde a duração 
de cada atividade é calculada através da estimativa da duração otimista, pessimista e mais provável 
da atividade. A duração única final da atividade será determinada através da média ponderada das 
três estimativas. 

Os pesos de cada tipo de duração podem variar de acordo com o projeto. Porém, a relação mais 
comum é de 1, 4 e 1 para a duração otimista, mais provável, e pessimista, ou seja, 

„ _ 1 xOpt + 4 xEst + 1 xPes 

Duraçao =----- 

onde Opt = duração otimista 

Est = duração mais provável 
Pes = duração pessimista 

A análise PERT possibilita uma precisão muito maior ao se estimarem durações de atividades. 

A análise PERT é utilizada em conjunto com a distribuição normal para determinar a probabilidade 
que o projeto tem de ser concluído em um determinado prazo, sendo esse processo extremamente 
importante no gerenciamento de riscos. 

Análises estatísticas mais sofisticadas podem ser realizadas, tais como cálculos de desvio-padrão, 
aproximação por curvas estatísticas, simulação de Monte Cario, etc. 

1.76.30utras Considerações Sobre a Duração das Atividades 

Uma atividade pode utilizar recursos em horário integral, ou em horários parciais. Recursos pouco 
qualificados, ou pouco especializados (operários em geral), devem ser utilizados, sempre que 
possível, em horários integrais, evitando-se, assim, a perda de tempo na troca das atividades, uma 
vez que o seu trabalho não é especializado. Os recursos altamente especializados e técnicos 
(consultores) ou recursos de supervisão (chefes e gerentes) devem ser utilizados em trabalhos 
parciais, característicos de supervisão, uma vez que sua presença não é exigida durante todo o tempo 
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da atividade e, por apresentar um custo elevado, necessita ser mais bem aproveitada. 

Os mecanismos mais comuns para alocação de recursos são as matrizes de atribuição de 
responsabilidades. Elas resolvem um dos problemas frequentes de gerenciamento de projetos, que é 
converter as relações hierárquicas dos organogramas funcionais em relações dinâmicas dentro do 
projeto. 
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Figura 4.7 - Matriz de Atribuição de Responsabilidades 







1.77Identifícar e Selecionar os Recursos e Profissionais para o 
Projeto (20) 

A finalidade dessa etapa é identificar todos os recursos que serão necessários para o projeto, 
selecioná-los de modo que eles estejam disponíveis para realizar as atividades do projeto. Os 
profissionais (recursos humanos) vão ser selecionados segundo os critérios estabelecidos no plano 
de gerenciamento de recursos humanos. 

Os recursos são todas as pessoas, materiais de consumo e equipamentos necessários para a 
realização da atividade. 

Na escolha dos recursos, o gerente de projeto deve atentar para diversos fatores, dentre eles, 

• disponibilidade do recurso, 

• custo, 

• capacitação (profissionais), 

• qualidade (equipamentos e materiais). 

Os recursos se subdividem nas seguintes categorias: 

• mão de obra (profissionais), 

• materiais, 

• equipamentos. 

São exemplos de recursos 

• pintores, • veículos, 

• areia, • papel, 

• computadores, • programadores. 

Dinheiro não deve ser considerado recurso. O capital e o custo de uma atividade estão agregados ao 
custo dos recursos nela envolvidos, a não ser que se esteja tratando de dinheiro físico (notas e 
moedas) que vão ser empregados como recurso físico no projeto (revestir uma parede de moedas 
para decorar um escritório, por exemplo). 



1.78Alocar Recursos nas Atividades (21) 


Após serem determinados os recursos que serão empregados no projeto, é preciso que esses recursos 
sejam atribuídos a cada atividade do projeto. É um processo trabalhoso e demorado, mas é a base de 
todo o cálculo de orçamentos e custos do projeto, bem como a única maneira de gerenciar a 
disponibilidade/alocação de cada recurso do projeto, calcular os estoques e gerenciar o recurso 
humano do projeto. 

Alocar recursos nas atividades exige experiência do gerente de projeto. Para isso, o executivo deve 
contar com o apoio e a experiência de todos os envolvidos no projeto, analisar outros projetos e 
consultar dados históricos. 

A alocação de recursos pode também ser calculada através de dados estatísticos e ensaios em 
pequena escala (piloto). 



1.79Criar o Plano de Gerenciamento de Pessoal (22) 


Nesse momento é criado o plano de gerenciamento de pessoal, onde todos os recursos alocados são 
apresentados, incluindo políticas de RH, remuneração e treinamento, bonificação, organogramas, 
matrizes de responsabilidades, diretórios do time do projeto, etc. 

Maiores detalhes sobre o plano de gerenciamento de recursos humanos podem ser encontrados no 
capítulo das áreas do gerenciamento de projetos (Parte III). 



1.80Inter-relacionar as Atividades e Definir Precedências 
(Diagrama de Rede) (23) 

O objetivo desta etapa do projeto é associar as atividades, estabelecendo precedências para que 
atividades interdependentes sejam identificadas e o cronograma do projeto seja determinado. 

Uma atividade que comece ou finalize antes que outra atividade possa começar é chamada 
predecessora. Uma atividade que dependa do início ou do final de outra atividade é chamada 
sucessora. 

Além das dependências, as atividades podem ter atrasos ou adiantamentos intencionalmente 
provocados, de modo a permitir um intervalo de tempo entre a predecessora e a sucessora, ou até 
mesmo uma sobreposição entre elas. 

1.80.1Definições 

Para se definir o inter-relacionamento entre as atividades de um projeto, é importante que se definam 
alguns parâmetros importantes relativos ao cronograma do projeto. São eles: 

• o início do projeto, 

• o término do projeto, 

• o início da atividade, 

• o término da atividade, 

• os calendários, 

• os feriados e dias especiais. 

Início do Projeto - É a data de início do projeto, isto é, o primeiro dia da primeira atividade a ser 
desenvolvida. Normalmente, é definida no objetivo do projeto (projetos calculados do início para o 
fim), mas pode ser calculada a partir da data de término do projeto (projetos calculados do fim para 
o início). 

Término do Projeto - É a data de término do projeto, isto é, o último dia da última atividade a ser 
desenvolvida. Normalmente, é calculada pelo projeto (projetos calculados do início para o fim), mas 
pode ser definida (projetos calculados do fim para o início). 

Início da Atividade - É a data e a hora em que a atividade se inicia. Pode ser um dado fixo do 
projeto ou calculada em consequência de suas atividades predecessoras. 

Término da Atividade - É a data e a hora em que a atividade termina. Normalmente, é calculada a 
partir da data de início da atividade e de sua duração. 

Calendários - Os calendários são utilizados para determinar e selecionar os dias de trabalho, ou 
folga, do projeto. Os calendários também devem ser utilizados para indicar horas específicas de 
trabalho para um determinado recurso. 

Feriados e Dias Especiais - Devem ser sempre inseridos para que não ocorram erros no 
gerenciamento das atividades. Dias com expediente especial (véspera de Natal e Ano Novo, etc.), 
além de dias em que não serão desenvolvidas atividades no projeto deverão ser considerados dias 
especiais, ou feriados, no projeto. 

Um projeto pode ter datas especiais para diferentes participantes do projeto, tais como férias, 



dispensas, etc. 

1.80.2Restrições de Datas nas Atividades 

As atividades podem ter diversos tipos de restrições quanto ao início ou ao término de sua execução. 
Essas restrições devem ser associadas aos tipos de interdependências entre as atividades. São elas 
as seguintes: 

• atividade que se inicia o mais rápido possível (as soon as possible ); 

• atividade que se inicia o mais tarde possível (as late as possible ); 

• atividade que se inicia não antes de um determinado dia (start no earlier than ); 

• atividade que se inicia não depois de um determinado dia (start no later than); 

• atividade que se inicia obrigatoriamente em uma data (must start on ); 

• atividade que se conclui, obrigatoriamente, em uma data (must finish on). 

1.80.3Tipos de Inter-relacionamentos 

As atividades podem ser inter-relacionadas de várias formas. As principais formas de inter- 
relacionamento são: 

• término para início - TI (finish to start - FS); 

• início para início - II (start to start - SS); 

• término para término - TT (finish to finish - FF); 

• início para término - IT (start to finish - SF). 

Término para Início (Finish to Start - FS) - A atividade sucessora somente se inicia com o tér min o 

da atividade predecessora. Exemplo: O telhado de uma casa somente pode ser construído quando as 
paredes tiverem sido erguidas. 

Predecessora L-i 


Sucessora 


Figura 4.8 - Relação de Tér min o para Início (TI ou FS) 

Início para Início (Start to Start - SS) - A atividade sucessora somente se inicia com o início da 

atividade predecessora. Essa relação faz com que duas atividades ocorram simultaneamente e 
resulta, na maioria das vezes, em economia de tempo e dinheiro. Por exemplo, ao instalar uma rede 
de computadores, pode-se programar o início da instalação física dos cabos com a instalação lógica 
dos computadores para que ocorram simultaneamente. 



Figura 4.9 - Relação de Início para Início (II ou SS) 







Término para Término (Finish to Finish - FF) - A atividade sucessora somente termina com o final 

da atividade predecessora. Essa relação faz com que as atividades se finalizem sincronizadas. Por 
exemplo, um computador somente pode ser considerado pronto quando as cópias de segurança dos 
dados tiverem sido realizadas. Isso significa que a atividade de preparo do computador ficará 
pendente até que as cópias dos dados de segurança estejam prontas. 



Predecessora 



Sucessora 


Figura 4.10 - Relação de Término para Tér min o (TT ou FF) 

Início para Término (Start to Finish - SF) - Relação pouco usual. Ocorre quando o fim de uma 
atividade depende do início de uma atividade anterior. Funciona de forma inversa à relação Término 

r 

para Início. E utilizado para substituições de procedimentos ou equipamentos. Por exemplo, uma 
empresa está substituindo sua central elétrica antiga por outra mais moderna. A central antiga deve 
permanecer funcionando até que a central nova esteja em pleno funcionamento. O problema não 
consiste em desligar a central antiga, mas, sim, em fazer com que a central nova funcione 
corretamente. 



Figura 4.11 - Relação de Início para Término (IT ou SF) 

1.80.4Defasagem e Adiantamento entre as Atividades 

Outro aspecto fundamental para o entendimento dos inter-relacionamentos entre as atividades em um 
projeto é o conceito de defasageme adiantamento. 

Diversas atividades em um projeto necessitam de um intervalo de tempo após a realização de sua 
predecessora, não podendo se iniciar logo após a atividade anterior como, por exemplo, as 
atividades de secagem, envelhecimento, amadurecimento, etc., que necessitam de um tempo mínimo 
de espera para o prosseguimento do projeto. Atividades de espera são dadas, na maioria das vezes, 
em durações corridas, incluindo as horas em que o projeto não trabalha (sábados, domingos, 
feriados, noites, etc.). 
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Figura 4.12 - Relacionamento entre atividades incluindo defasagens (atrasos) 

















Os adiantamentos funcionam inversamente aos atrasos. Seu objetivo é adiantar o cronograma do 
projeto, favorecendo a realização de atividades em paralelo. A técnica de reduzir a duração do 
projeto através dos adiantamentos é denominada Paralelismo ou fast tracking 
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Figura 4.13 - Relacionamento entre atividades adiantadas entre si 

1.80.5Diagrama de Rede 

O inter-relacionamento entre as atividades do projeto compõe um todo organizado, denominado 
diagrama de rede, ou vulgarmente conhecido como rede PERT ( Program Evaluation and Review 
Technique). O diagrama de rede evidencia os inter-relacionamentos entre as atividades no projeto 
global. 

O diagrama de rede tem sua origem no meio militar, com uma associação entre a marinha e as 
empresas Lockheed & Booz e Allen & Hamilton , em 1958, no desenvolvimento dos projetos de 
construção da série de submarinos atômicos Polaris do governo norte-americano. 

As vantagens do diagrama de rede são as seguintes: 

• simples entendimento; 

• interdependência entre as atividades bem-defmida. 

As desvantagens do diagrama de rede são as seguintes: 

• apresenta relatórios muito extensos; 

• não mostra uma relação visual entre as durações das atividades; 

• é de difícil manipulação. 

Existem dois tipos de diagramas de rede, que são: 

• AOA (Activity on Arrow ) - apresenta o diagrama com atividades representadas por setas que 
ligam um estado inicial a um estado final. É empregado principalmente quando se gerenciam 
projetos sem o computador. 

Ha* 2 
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Figura 4.14 - Rede PERT AOA 

• AON (. Activity on Node) - apresenta as atividades nos nós entre as setas. É a visualização 
mais comum atualmente, por ser gerada automaticamente pela maioria dos softwares de 
gerenciamento de projetos. 




























Figura 4.15 - Rede PERT AON 

1.80.6Diagrama de Gantt 

Outra forma muito comum de representação gráfica para cronogramas é o diagrama de Gantt , ou 
diagrama de barras. O diagrama utiliza barras horizontais, colocadas dentro de uma escala de tempo. 
O comprimento relativo das barras determina a duração da atividade. As linhas conectando as barras 
individuais em um Diagrama de Gantt refletem as relações entre as atividades. 

O diagrama de Gantt é a mais antiga técnica de administração de projetos. Foi criado por Henry 
Gantt no início do século, como objetivo de atender a fins militares e estratégicos. 
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Figura 4.16 - Diagrama de Gantt 

As principais vantagens do Diagrama de Gantt são as seguintes: 

• simples entendimento; 

• visualização de atrasos com facilidade; 

• escala de tempo bem definida. 

Suas principais desvantagens são as seguintes: 

• inadequação para grandes projetos; 

• difícil visualização de dependências; 

• vaga descrição de como o projeto reage a alterações de escopo. 

O diagrama de Gantt é a visualização-padrão da maioria dos softwares de gerenciamento de 
projetos. 

















































1.81Fazer a Conciliação dos Recursos Superalocados ou 
Indisponíveis (24) 

Após terem sido concluídos o cálculo da duração das atividades, a alocação de recursos e os inter- 
relacionamentos entre as atividades (etapas 19, 21 e 23), é necessário verificar se nenhum recurso 
está alocado em quantidade superior ao limite máximo disponível para aquele período. 

A figura a seguir mostra o recurso João em conflito nas atividades A e B (supondo que ele não está 
alocado parcialmente nessas atividades, o que retiraria o conflito). 



Figura 4.17 - Recurso João superalocado nas atividades A e B 

Existem diversas formas de se conciliar o recurso superalocado na figura anterior. Dentre as mais 
importantes, podem-se destacar as seguintes: 

• substituição do recurso por outro similar que esteja disponível; 

• troca da escala de trabalho do recurso superalocado; 

• realização de trabalho em regime de horas-extras; 

• nivelamento ou redistribuição de recursos. 

1.81.1 Substituição do Recurso por Outro que Esteja Disponível 


Significa substituir o recurso em conflito de alocação por outro que possua, aproximadamente, a 
mesma qualificação para realizar o trabalho e que esteja disponível no período. 
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Figura 4.18 - Recurso João substituído pelo recurso Roberto na atividade B 



















































































Vantagens 

Desvantagens 

• Não altera os custos diretos 
do projeto; 

• o recurso que irá substituir 
normalmente está disponível 
na própria empresa 

• As pessoas são diferentes, 
logo sua produtividade 
também; 

• se o substituto fosse o ideal, 
já teria sido escolhido 
naturalmente pelo projeto 
como primeira opção, e não 
como substituto 


Tabela 4.1 - Vantagens e desvantagens da substituição de recursos 

1.81.2Troca da Escala de Trabalho 

Significa fazer com que o recurso superalocado trabalhe em uma jornada maior durante o período 
problemático e folgue posteriormente, formando um banco de horas de trabalho. 



i em escala , , João 
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Figura 4.19 - Recurso João trabalhando em escala especial na semana 01 e folgando na semana 02 


Vantagens 

Desvantagens 

• Custo adicional zero para o 
projeto; 

• não existe troca do recurso, 
garantindo a produtividade e 
a eficiência do processo 

• Dificuldades legais quanto 
aos direitos do trabalhador; 

• cansaço e perda de 
produtividade em escalas de 
trabalho longas 


Tabela 4.2 - Vantagens e desvantagens da troca da escala de trabalho 

1.81.3Regime de Trabalho em Horas-Extras 

Significa fazer com que o recurso superalocado trabalhe em regime de horas-extras durante o período 
em que está sendo superalocado, sendo remunerado de forma diferenciada por esse esforço. 
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Figura 4.20 - Recurso João trabalhando em regime de horas-extras na semana 01 


Vantagens 

Desvantagens 

• Não existe troca do recurso, 
garantindo a produtividade e 
a eficiência do processo; 

• relação trabalhista 
legalizada. 

• Custo adicional elevado 
para o projeto; 

• vício do empregado na 
realização de trabalho em 
hora-extra; 

• cansaço e perda de 
produtividade em escalas de 
trabalho longas 


Tabela 4.3 - Vantagens e desvantagens do trabalho em horas-extras 

1.81.4Nivelamento de Recursos 

É a forma mais comum de se resolverem problemas que envolvem alocação de recursos. Consiste em 
atrasar as atividades segundo critérios de prioridades, restrições ou duração previamente 
determinados, de modo a retirar o sincronismo que possa existir entre as atividades que possuem 
recursos superalocados. O nivelamento normalmente atrasa o término do projeto. 

O algoritmo utilizado para o nivelamento de recursos é mostrado a seguir. 
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Figura 4.21 - Algoritmo do nivelamento de recursos 

Como exemplo de nivelamento de recursos, tem-se o diagrama de Gantt. 

































Antes do Nivelamento 
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Figura 4.22 - Diagrama de Gantt do projeto antes e depois do nivelamento 


Vantagens 

Desvantagens 

• Não altera o custo direto do 
projeto, alterando apenas o 
fluxo de pagamentos: 

• processo menos traumático 
para os recursos. 

• Na grande maioria dos 
casos gera atrasos no 
cronograma do projeto; 

• algoritmo complexo de 
cálculo, sendo viável apenas 
se calculado por programas 
de computador 


Tabela 4.4 - Vantagens e desvantagens do nivelamento de recursos 

1.81.5Conclusão 

É importante ressaltar que não existe uma estratégia correta para se conciliarem os recursos. Cada 
caso deve ser estudado isoladamente e, em projetos complexos, a análise correta da melhor técnica 
de conciliação de recursos pressupõe o uso de praticamente todas as estratégias. 






















































































1.82Calcular o Caminho Crítico (CPM) (25) 

Esta etapa é a responsável por determinar o caminho crítico do projeto que é constituído pelas 
atividades mais importantes do projeto. Qualquer atraso nas atividades do caminho crítico implica 
um atraso no término do projeto. A duração do caminho crítico interfere diretamente na duração do 
projeto. 

O caminho crítico também é definido como o caminho com a menor folga de tempo 
possível (usualmente zero) e determina a duração do projeto. 

As atividades que compõem o caminho crítico são chamadas atividades críticas e, se atrasadas, 
causam um atraso na execução do projeto. As modificações de tempo em atividades não críticas não 
têm efeito sobre a data de término do projeto. 

Alguns softwares de gerenciamento de projetos permitem que se determinem caminhos críticos que 
não necessariamente tenham folga zero. Nesse caso, é possível se estabelecerem outras regras para o 
caminho crítico, como por exemplo identificar como crítica toda atividade que tenha folga menor do 
que três dias. 

1.82.1Definições Importantes 

Para que se compreenda melhor o caminho crítico, é importante que se conheçam algumas definições. 
São elas as seguintes: 

• início mais cedo de uma atividade; 

• início mais tarde de uma atividade; 

• término mais cedo de uma atividade; 

• término mais tarde de uma atividade; 

• folga livre (individual); 

• folga total. 

Início mais cedo de uma atividade - É a data de início mais otimista da atividade, sem que tenha 
ocorrido nenhum atraso, todos os passos anteriores tenham sido realizados adequadamente e todas as 
interdependências comas predecessoras, respeitadas. 

r 

Início mais tarde de uma atividade - E a data de início mais pessimista da atividade, sem que, no 
entanto, o projeto seja prejudicado no todo, isto é, é a última data em que se pode iniciar a atividade 
sem se prejudicar o projeto. 

Término mais cedo de uma atividade - É a data de término mais otimista para a atividade, não 
utilizando nenhuma folga. 


TMC =IMC +D 

Onde, TMC = Término mais cedo 
IMC = Início mais cedo 
D = Duração estimada 

Término mais tarde de uma atividade - É a última data para o término da atividade sem 
comprometer o término do projeto. 


TMT=IMT-D 


Onde. TMT = Término mais tarde 
IMT = Início mais tarde 
D = Duração estimada 

Folga Total - É a folga de tempo de uma atividade que não provoca nenhum atraso no projeto, 
podendo, no entanto, alterar as atividades sucessoras, desde que essas não sejam atividades críticas. 
Quando uma atividade que possui folga total utiliza toda a sua folga para realizar o trabalho, ela 
força, automaticamente, que todas as atividades diretamente sucessoras a ela se tornem atividades 
críticas (folga zero), pois a folga individual de cada uma delas foi utilizada pela predecessora na 
realização de seu trabalho. 

O valor da folga total é dado pela diferença entre o início mais tarde e o término mais tarde da 
atividade, ou seja, 

FT = TMT - IMT 
Onde. FT = Folga total 

TMT = Término mais tarde 
IMT = Início mais tarde 
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Figura 4.23 - Folga total para a atividade B é de 5 dias, para a C, de 3, para a D, de 2, enquanto a folga para as atividades A e E 
é zero 

Folga Livre ou Individual - É a folga de tempo de uma atividade de modo a não provocar nenhum 
atraso na atividade sucessora, independentemente dessa atividade ser ou não crítica. 

O valor da folga livre é dado pela diferença entre o início mais cedo da atividade sucessora e o 
término mais cedo da atividade predecessora, ou seja, 








































FL = IMC j -TMC, 


Onde, FL = Folga livre 

TMC, = Término mais cedo da predecessora 
IMCj = Início mais cedo da sucessora 
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Figura 4.24 - Diagrama de Gantt e folga livre ou individual de 2 dias para a atividade B, de 1 dia para a atividade C e de 2 dias 
para a atividade D 

Finalmente, após se determinarem todas as datas e folgas, pode-se construir o caminho crítico, 
destacando-se a cadeia de atividades que apresenta menor folga ou folga zero. 
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Figura 4.25 - Caminho crítico de um projeto (A e E são críticas) 


































































1.83Desen volver o Cronograma do Projeto (26) 


Esta etapa tem como objetivo determinar exatamente qual a data de início e término de cada 
atividade, uma vez que os recursos, as durações e as interdependências já estão estabelecidos. 

O cronograma do projeto pode ser apresentado de diferentes formas, porém as mais comuns são: 

• Diagrama de rede, 

• Tabelas com listas de atividades, 

• Gráfico de Gantt, 

• Gráfico de marcos ou etapas. 

Os detalhes que suportam o cronograma também são produzidos nessa etapa, como, por exemplo, a 
tabela de alocação dos recursos e reservas de contingência, dentre outros. 



1.84Criar o Plano de Gerenciamento de Prazos (27) 


Logo após a criação do cronograma, é importante que se estabeleça um plano de gerenciamento de 
prazos, uma vez que todos os procedimentos de controle do tempo no projeto passam a ser 
fundamentais depois de estabelecido o cronograma. 

Maiores detalhes sobre o plano de gerenciamento de prazos podem ser obtidos no capítulo sobre as 
áreas do gerenciamento de projetos, apresentado anteriormente. 



1.85Calcular o Custo das Atividades e do Projeto (Orçamento) (28) 


Custo é a quantidade de capital necessária para se realizar uma atividade ou um projeto. 

O custo de uma atividade é calculado como a soma dos custos dos recursos envolvidos na atividade 
cornos custos indiretos da atividade (custos de supervisão, etc.). 

1.85.1Custos de Recursos 

Existem duas formas de se atribuírem custos a um recurso: 

• custo por empreitada (custo por uso); 

• custo variável por hora de trabalho. 

O custo por empreitada é utilizado para recursos que irão cobrar por um determinado trabalho, 
independentemente do tempo que se gaste para fazê-lo. Também é utilizado para materiais que serão 
consumidos pelo projeto. 

O custo variável por hora de trabalho é atribuído a recursos que serão remunerados por hora 
trabalhada, podendo, inclusive, incluir os custos decorrentes de horas-extras. Para recursos do tipo 
equipamentos, o custo por hora deve ser o valor da depreciação do bem ou do aluguel por hora de 
utilização. 

Como exemplo, pode-se contratar um engenheiro para fazer o cálculo estrutural de uma obra e ele ser 
remunerado pelo trabalho realizado (custo por empreitada). 

Outro exemplo é quando um operário trabalhar em um projeto complexo e grande, sendo remunerado 
através de seu salário mensal. O custo desse operário deve ser incluído no projeto como custo 
variável por hora de trabalho. O custo por hora é encontrado pela divisão do salário mensal pelas 
horas trabalhadas no mês, sem deixar de considerar os efeitos de produtividade do recurso. 

1.85.2Custos Indiretos 


Outra parte do custo da atividade muito importante são os custos indiretos, provenientes da infraestrutura administrativa e 
de staff áo projeto. Todos os funcionários da supervisão, da administração, bem como todos os custos de instalações fisicas 
do projeto, precisam ser incluídos como custo indireto. 


1.85.3Estimativa de Custos por Pacotes de Trabalho 

O WBS pode ser usado para estimativas de custos das fases do projeto e até de todo o projeto. O 
custo da fase é a soma dos custos das atividades a ela pertencentes. O custo total do projeto é a soma 
dos custos de suas fases. Esse processo também é conhecido como Bottom Up estimating. 





Figura 4.26 - WBS como ferramenta para o cálculo do custo do projeto 

1.85.40rçamento 

Orçamentos são as atribuições financeiras dos recursos necessários para se completar o projeto, 
normalmente expressos em unidades monetárias. A maioria dos orçamentos é dada através de 
tabelas, como a exibida a seguir. 


Atividade 

Orçamento 

TOTAL 

Custo 

Fixo 

Custo 

Direto 

Custo 

Indireto 

A 

$3.00 

$12.00 

$0.00 

$15,00 

B 

$0.00 

$15.00 

$4.00 

$19,00 

C 

$5.00 

$0,00 

$0.00 

$5,00 

D 

$2.00 

$10.00 

$7.00 

$19,00 

TOTAL 

$10,00 

$37,00 

$11,00 

$58,00 


Figura 4.27 - Exemplo de orçamento distribuído por atividade e por tipo de custo 

1.85.5Fluxo de Caixa 

Uma das formas mais importantes de se analisarem os custos dos projetos é através do fluxo de 
caixa, ou fluxo de desembolso do projeto. Ele associa os custos de cada atividade ao cronograma do 
projeto, permitindo que se analisem o desembolso médio e o custo médio de cada atividade do 
projeto. É também conhecido como cost baseline. 


Atividade 

Custo por Semana 

TOTAL 

SI 

S2 

S3 

S4 

A 

$2.00 

$3.00 

$2.00 

$8.00 

$15,00 

B 

$4.00 

$2.00 

$9.00 

$4.00 

$19,00 

C 

$1.00 

$1,00 

$1.00 

$2.00 

$5,00 

D 

$3.00 

$8.00 

$3,00 

$5.00 

$19,00 

TOTAL 

$10,00 

$14,00 

$15,00 

$19,00 

$58,00 


Figura 4.28 - Exemplo de fluxo de caixa de um projeto 





















































1.86Criar Planos de Custos, Riscos e Aquisições (29, 30 e 31) 


Essas etapas têm como objetivo finalizar os planos restantes do projeto, uma vez que todas as 
informações necessárias para esses planos já estão disponíveis; e é necessário que se tenha esses 
planos para que o plano do projeto seja estabelecido. Conforme já visto, esses planos têm como 
objetivo administrar e controlar determinadas áreas do projeto de maneira formal, descrevendo os 
procedimentos que serão utilizados para gerenciar os custos, os riscos e os suprimentos do projeto. 
Maiores detalhes sobre os planos de gerenciamento de custos, riscos e suprimentos podem ser 
obtidos no capítulo sobre as áreas do gerenciamento de projetos, apresentado anteriormente. 



1.87Desen volver o Plano de Gerenciamento do Projeto (32) 


Esta etapa tem como objetivo desenvolver um documento formal que será utilizado para gerenciar e 
controlar a execução do projeto, sendo distribuído conforme estabelecido no plano de gerenciamento 
das comunicações. 

O Plano Global do Projeto deve conter: 

• a visão geral dos objetivos, metas e escopo do projeto de uma maneira resumida e macro para 
atender aos altos executivos do projeto (pequena introdução do assunto); 

• o objetivo detalhado do projeto para atender ao gerente do projeto e ao time do projeto; 

• o nome e as responsabilidades do gerente e do time principal do projeto (matriz de 
responsabilidades); 

• o organograma do projeto; 

• estudo técnico da solução a ser adotada pelo projeto; 

• aspectos contratuais quanto à participação de elementos externos ao projeto; 

• Estrutura Analítica do Projeto ou WorkBreakdown Structure (WBS); 

• cronogramas; 

• diagrama de Gantt; 

• diagrama de rede; 

• principais marcos com suas datas; 

• utilização de recursos pelo projeto (relatório comas funções); 

• orçamento, análise de custos e fluxos de caixa; 

• necessidade de contratação e treinamento de pessoal; 

• formas previstas de avaliação dos índices de qualidade e desempenho a serem atingidos pelo 
projeto; 

• potenciais obstáculos a serem enfrentados pelo projeto e possíveis soluções; 

• lista de pendências; 

• planos das áreas de conhecimento: 

• Plano de Gerenciamento de Escopo; 

• Plano de Gerenciamento de Prazos (Tempo); 

• Plano de Gerenciamento de Custos; 

• Plano de Gerenciamento da Qualidade; 

• Plano de Gerenciamento de Recursos Humanos; 

• Plano de Gerenciamento das Comunicações; 

• Plano de Gerenciamento de Riscos; 

• Plano de Gerenciamento de Aquisições. 

A maioria dos softwares utilizados para o gerenciamento de projetos facilita muito a criação do 
plano de gerenciamento do projeto, uma vez que a maior parte das informações aqui necessárias já 
foi calculada por eles em etapas anteriores. 



1.88Aprovação do Plano de Gerenciamento do Projeto (33) 


Após ter sido criado o plano do projeto, torna-se necessária a aprovação formal do plano 
operacional por todos os envolvidos, incluindo clientes, fornecedores e outros elementos da 
organização. Essa aprovação deve ser realizada através de uma reunião e posterior aprovação por 
escrito, autorizando o início da execução do projeto. 

No caso de não aprovação é preciso que o plano do projeto seja revisto, caso essa ação seja 
possível. Caso contrário, o projeto pode ser abortado ou redefinido (passo 33A - Rever viabilidade 
do projeto ou abortar). 



1.89Arquivar o Plano de Gerenciamento do Projeto no Livro Geral 
do Projeto (Linha de Base) (34) 


O plano do projeto e todos os seus documentos complementares devem ser arquivados no livro geral 
do projeto para posterior utilização como base de referência ( baseline). 



FASE DE EXECUÇÃO E FASE DE 
CONTROLE 



1.90Executar o Pacote de Trabalho (Atividades) (35) 


A execução do projeto consiste na realização das atividades previstas no plano do projeto. A 
execução é feita através da realização dos pacotes de trabalho ( workpackage ). O pacote de trabalho 
é considerado concluído quando ocorre a entrega ( delivery ). A entrega é qualquer resultado do 
trabalho que pode ser facilmente medido pelo projeto. Temas seguintes características: 

• facilmente mensurável; 

• tangível pelos executantes; 

• conclusão identificável de maneira simples e direta. 

A finalização de todos os pacotes de trabalho e a realização de todas as entregas do projeto 
representam a conclusão do projeto. 

r 

E fundamental ressaltar que a execução dos pacotes de trabalho materializa todo o 
planejamento do projeto e, portanto, todas as falhas cometidas em etapas anteriores ficam 
evidentes durante a execução. 



1.91Executar Atividades Auxiliares: Aquisições, Recursos 
Humanos, Comunicações e Qualidade (36) 


Em paralelo à execução dos pacotes de trabalho, uma série de atividades é necessária para garantir 
que os processos de controle e replanejamento sejam eficazes. 

Baseado nos processos estabelecidos no PMBOK, podem ser estabelecidos os seguintes processos, 
por área: 

Comunicações - Durante a execução do projeto, é importante que as informações sejam distribuídas 
aos interessados no prazo e na profundidade desejada, conforme estabelecido no plano de 
comunicações. Além disso, todas as atividades relacionadas ao gerenciamento das expectativas dos 
interessados devem ser realizadas. 

Recursos Humanos - Três dos quatro processos de recursos humanos descritos no PMBOK são 
desenvolvidos nesta etapa. A mobilização da equipe permite com que todos os recursos humanos 
necessários para o projeto estejam disponíveis e prontos para o trabalho. O desenvolvimento do time 
é realizado através de treinamento presencial, ou treinamento “on the job ”, políticas de premiação 
por resultados e atividades que potencializam o trabalho das pessoas como um time. Além disso, 
todas as atividades relacionadas ao gerenciamento da equipe são realizadas também. 

Qualidade - Nessa etapa também é importante garantir que os resultados específicos do projeto 
estejam de acordo com os padrões de qualidade estabelecidos. A garantia de qualidade faz essa 
avaliação, bem como identifica causas de resultados insatisfatórios e meios para eliminá-los. 

Aquisições - Parte do processo de aquisições é realizada na execução do projeto, incluindo 
solicitação de respostas dos fornecedores e a escolha dos fornecedores, conforme estabelecido no 
plano de gerenciamento de aquisições. 



1.92Realizar a Análise de Valor Agregado para Avaliação de 
Desempenho (37) 

Existem diversas formas de se avaliar o desempenho de um projeto, incluindo análise de variância e 
tendências, porém a análise de valor agregado é uma das mais precisas e poderosas técnicas 
disponíveis. 

A análise de valor agregado {Earned Value Analysis ) é a responsável pelo acompanhamento 
financeiro de todo o projeto. Ela tem como objetivo detalhar os custos do projeto de forma a 
acompanhar com precisão as evoluções do seu custo. 

Valor agregado é um conceito prático e simples que tem foco na relação entre os custos reais 
consumidos e o trabalho realizado no projeto. O objetivo está no desempenho real obtido como que 
foi gasto, ou seja, o que foi obtido pelo projeto em relação ao gasto financeiro para atingir aquele 
resultado. O conceito de valor agregado requer que as medidas de despesa-desempenho sejam 
estabelecidas dentro de um cronograma físico do projeto. Então, através da relação entre o valor 
agregado e o valor planejado do trabalho dentro do tempo pode dar maior precisão ao controle do 
que apenas controles financeiros ou de prazos isolados. Flemming e Green propõem que o valor 
agregado funciona como um tipo de “alarme”, permitindo ao gerente de projeto avaliar se está 
consumindo mais dinheiro para realizar uma determinada tarefa, ou se está apenas gastando mais 
naquele momento porque o desenrolar do projeto está sendo acelerado. Isso permitirá que sejam 
tomadas ações corretivas e preventivas com a devida antecedência. 

1.92.1Conceitos~ 

Dentro da análise de valor agregado, é importante que se conheçam alguns termos comuns, listados a 
seguir. 

Conceitos de orçamento, custos reais e valor agregado 

BCWS ou COTA (custo orçado do trabalho agendado) - Valor que indica a parcela do orçamento 
que deveria ser gasta, considerando o custo de linha da base da atividade, atribuição ou recurso. O 
COTA é calculado como os custos de linha de base divididos em fases e acumulados até a data de 
status, ou data atual. É o custo proveniente do orçamento. O PMI utiliza a sigla PV ( Planned Value) 
para representar o BCWS. 

BCWP ou COTR (custo orçado do trabalho realizado) - Valor que indica a parcela do orçamento 
que deveria ser gasta, considerando o trabalho realizado até o momento e o custo de linha de base 
para a atividade, atribuição ou recurso. O COTR é calculado como o percentual da atividade 
realizada multiplicado pelo seu orçamento. O COTR também é denominado valor agregado. O PMI 
utiliza a sigla EV Ç Earned Value) para representar o BCWP. 

ACWP ou CRTR (custo real do trabalho realizado) - Mostra os custos reais incidentes para o 
trabalho já realizado por um recurso ou atividade, até a data de status, ou data atual do projeto. O 
PMI utiliza a sigla AC ( Actual Cost) para representar o ACWP. 




Figura 5.1 - Exemplo gráfico do BCWS, BCWP e ACWP ao longo do tempo para um determinado projeto. 

Conceitos de análises de variações de custo e prazo 

CV ou VC (variação do custo) - É a diferença entre o custo previsto para atingir o nível atual de 
conclusão (BCWP) e o custo real (ACWP), até a data de referência. Se CV for positiva, o custo do 
trabalho agregado estará aquém do valor realmente gasto (custo real); se for negativa, a atividade 
está agregando um valor inferior ao que se gastou no trabalho e, continuada essa tendência significará 
que o projeto tem uma grande probabilidade de ser concluído com um gasto superior ao orçado. É 
traduzido oficialmente pelo PMI como VC ou variação de custos. 

CV = BCWP - ACWP 

SV ou VP (variação de prazos) - É a diferença, em termos de custo, entre o Valor Agregado 
(BCWP) e a agenda de linha de base (BCWS). Se SV for positiva, o projeto estará adiantado; se for 
negativa, o projeto estará atrasado. É traduzido oficialmente pelo PMI como VP ou variação de 
prazos. 

SV =BCWP -BCWS 

TV ou VT (variação de tempo) - É a diferença, em termos de tempo, entre o previsto pelo projeto e 

r _ 

o realizado. E encontrado graficamente pela projeção da curva de BCWS e BCWP, encontrando a 
data em que o BCWS agrega o mesmo valor de BCWP. A diferença entre a data de referência e essa 

r __ 

data representa o atraso ou adiantamento do projeto. E traduzido oficialmente pelo PMI como VT ou 
variação de tempo. 






Figura 5.2 - Análise de Valor Agregado com as determinações de CV, SV e TV 

Conceitos de índices de desempenho 

SPI ou IDP (índice de desempenho de prazos) - É a divisão entre o valor agregado (COTR) e a 
agenda da linha de base (COTA). Se o IDP for menor que 1, indica que o projeto está atraso. Se o 
IDP for maior que 1, indica que o projeto está adiantado. Se o IDP for igual a 1, indica que o projeto 
está exatamente no prazo. O IDP mostra a taxa de conversão do valor previsto em valor agregado. 


BCWP 

BCWS 

CPI ou IDC (índice de desempenho de custos) - É a divisão entre o valor agregado (COTR) e 
custo real (CRTA). Se o IDC for menor que 1, indica que o projeto está gastando mais do que o 
previsto. Se o IDC for maior que 1, indica que o projeto está custando abaixo do orçamento. Se o 
IDC for igual a 1, indica que o projeto está exatamente no orçamento. O IDC mostra qual a conversão 
entre os valores gastos e os valores agregados no projeto. 
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Figura 5.3 - Avaliação dos índices de desempenho de prazo e custo 

1.92.2Exemplo 

Para melhor diferenciar o gerenciamento por valor agregado do gerenciamento tradicional, tem-se um 
exemplo de um projeto que custe $60 e tenha 4 meses de prazo para execução. Supondo que o gasto 
do capital seja linear, tem-se um consumo de $15 (COTA ou BCWS) em cada mês. 

No final do terceiro mês, o gerente de projeto calcula os gastos do projeto e chega a um total de $30 
(CRTR ou ACWP). Uma análise financeira isolada evidencia que o projeto está $15 abaixo dos 
gastos previstos (45-30). Isso podería representar uma percepção de economia para o projeto. A 
grande pergunta a ser feita agora é “Será que todos os 30 foram convertidos em resultados para o 
projeto?” 



Figura 5.4 - Análise Custo x Tempo Tradicional 

Coma análise de valor agregado, torna-se necessária a inserção de um novo dado: os ganhos físicos 
reais ou valor agregado (COTR ou BCWP). Supondo-se que, para os dados anteriormente 
mencionados, os produtos obtidos no final do terceiro mês agregam $25, ou seja, somente $25 de 
produto foram produzidos (COTR ou BCWP). 


















Tempo (meses) 


Figura 5.5 - Análise de Valor Agregado 

Essa terceira dimensão permite concluir que o projeto está com trabalhos atrasados, uma vez que 
foram agregados trabalhos de apenas $25 dos $45 previstos para esses três meses, estando abaixo do 
planejado em $20, ou seja, o projeto está atrasado em trabalho em $20 (\A ou SV). Essa conclusão é 
de fundamental importância, pois proporciona conclusões diferentes das obtidas pelo gerenciamento 
tradicional. Outra conclusão é que o projeto consumiu $30 para agregar somente $25. Isso representa 
que, além do atraso nos prazos de execução, tem-se um aumento nos custos do projeto em $5 nesse 
período (VC ou CV). 

Ao se calcularem os índices de desempenho, tem-se que o IPA ou SPI é de 0,555 (55,5%). Isso 
significa que apenas 55,5% do tempo gasto está sendo transformado em resultados, 44,5% do tempo 
está sendo desperdiçado. Com relação ao índice de desempenho de custos (IPC ou CPI), tem-se um 
valor de 0,833 (83,3%). Isso significa que 83,3% do dinheiro gasto foi convertido em resultados e 
16,7% do dinheiro está sendo desperdiçado. 

















1.93Executar o Controle de Escopo, Tempo, Custos, Qualidade, 
RH, Comunicação, Riscos e Aquisições (38) 


Esta etapa tem como objetivo avaliar cada uma das áreas do projeto de modo isolado, procurando 
identificar variações de forma a possibilitar o controle 



1.94Executar o Controle Integrado de Mudanças (39) 


Esta etapa é o centro de todo o processo de controle do projeto. Seu objetivo é garantir que o projeto 
está sendo realizado conforme o plano e, no caso de mudanças nele, garantir que elas são benéficas 
para o projeto. 

Os objetivos do controle geral das mudanças são: 

• manter a integridade das linhas de base de desempenho estabelecidas no plano; 

• coordenar as mudanças através das áreas do projeto, garantindo que o todo seja beneficiado. 
Por exemplo, um atraso na realização de uma determinada atividade pode influenciar 
diretamente nos custos, nos riscos, na qualidade, etc., do projeto. 

É no controle geral das mudanças que o gerente do projeto é exigido em seu limite, uma vez que o 
nível de esforço do projeto está em sua plenitude, e é necessária uma avaliação global de todos os 
fatos e suas consequências para que o projeto não entre em um processo rápido de degeneração e 
descontrole. 

Praticamente toda a equipe que planejou o projeto é exigida nessa fase para que se consiga 
estabelecer um sistema de controle de mudanças. 



1.95Todos os Trabalhos Foram Concluídos? (40) 

Esta etapa verifica se todos os pacotes de trabalho foram executados e se todas as entregas foram 
efetuadas. Caso os trabalhos tenham sido concluídos, o projeto vai para a fase de finalização. Caso 
contrário, o próximo pacote de trabalho deve ser realizado (retorno à etapa 35). 



FASE DE ENCERRAMENTO 



1.96Auditar e Validar o Resultado do Projeto com o Cliente / 
Patrocinador (41) 


Esta etapa tem como objetivo avaliar o resultado do projeto junto ao cliente ou patrocinador para 
obter o aceite do projeto. 

Na maioria das vezes, a validação dos resultados é feita através de auditoria. A auditoria pode ser 
definida como o exame analítico e pericial que segue o desenvolvimento de projetos, de modo a 
avaliar se o resultado obtido está em conformidade com o previsto nas suas definições, sendo um 
subsídio técnico para o aceite do projeto. 

Diversas organizações internacionais são especializadas em auditar projetos de grande porte, 
especialmente para órgãos e empresas do governo, organizações militares e multinacionais. 

Lewis propôs um relatório de auditoria simples para projetos pequenos e simples. Sua elaboração e 
utilização são fáceis e diretas. O modelo de auditoria simplificado é mostrado a seguir. 


AUDITORIA DO PROJETO 


Projeto - 

Auditor - 
Período - De 


Data - 


Comparação com os objetivos 


Adequada 


Inferior ao 
Objetivo 


Superior 
ao Objetivo 


desempenho 
Custo _ 

Tempo _ 

Escopo 


Sim 


Parcialmente 


Nào 


O projeto atendeu aos objetivos 

Caso o projeto não tenha atingido seus objetivos, quais fatores 
contnbuíram para os resultados negativos? 


0 que foi realizado de forma adequada? 


0 que poderia ter sido feito melhor? 


Quais as recomendações para futuros projetos? 


0 que poderia ter sido realizado de forma diferente? 


Que aprendizado pode-se retirar do projeto? 


Figura 6.1 - Modelo de formulário simplificado para auditoria de projetos 

O produto desse processo é um documento de aceite formalizado pelo cliente ou patrocinador, 
garantindo que os produtos do projeto foram atingidos, encerrando a responsabilidade direta dos 
executantes sob o projeto, a não ser em projetos com garantia contratual estabelecida. 

























1.97Discutir as Falhas Cometidas Durante o Projeto para Servirem 
de Base a Futuros Projetos (42) 


Com base na auditoria do projeto, deverão ser discutidas as falhas cometidas, de forma a possibilitar 
o aprendizado para que, em projetos futuros, essas falhas não voltem a ocorrer, e os envolvidos 
estejam mais capacitados. Todas as discussões e conclusões acertadas entre os envolvidos devem ser 
registradas no livro geral do projeto. 



1.98Encerrar os Contratos Pendentes (43) 


Antes de se concluir o projeto, é importante que todos os contratos criados durante os trabalhos 
sejam liquidados, com exceção dos contratos que se referem a serviços posteriores ao projeto, tais 
como serviços de garantia e manutenção. Essa etapa evita que pendências relativas ao projeto sejam 
mantidas após seu término. 



1.99Desmobilizar o Time e a Estrutura do Projeto (44) 


Antes de se concluir o projeto, é importante que todo o time seja desmobilizado, bem como toda a 
estrutura de escritórios, equipamentos e administração do projeto. Em projetos que envolvem um 
número elevado de recursos humanos durante sua execução, a maioria deles é desmobilizada 
imediatamente após o término dos serviços, para evitar um aumento nos custos relativos à equipe. 



l.lOOFinalizar o Livro do Projeto e Ter o Projeto Concluído (45 e 
46) 


Depois de todas as discussões sobre o projeto, o livro geral do projeto deve ser concluído, levando 
a assinatura dos envolvidos. O livro geral do projeto deve ser arquivado na biblioteca da empresa, 
ou em outra área predefinida para arquivamento de projetos. 



2. QUESTÕES PARA REVISÃO 


1. Quem deve preparar o Termo de Abertura? Justifique. 

2. Diferencie a Declaração de Escopo do Termo de Abertura. 

3. Diferencie pacote de trabalho de dicionário da WBS. 

4. Explique os dois mecanismos mais utilizados na redução de prazos em projetos. 

5. Explique como a adição de recursos em uma atividade pode ou não reduzir sua duração. 

6. Quais são as principais técnicas para resolver problemas de alocação de recursos? 

7. O que deve estar contido no plano de gerenciamento de riscos? 

8. Qual a importância do controle integrado de mudanças? 

9. Qual a importância da auditoria nos projetos? 



3. PALAVRA CRUZADA 


Modelo Geral de Projetos 
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6 Forma Oe te cnar aHemaDva» oe 
condução <3o projeto 

6 Variação oe custos do projeto 
utilizando a anaiis« de valor 
agregado 

9 Resultados flsloos ou 

serro-produtos, obtidos ao longo 
do projeto 

11 Produto a ser entregue no ma« 
bano ntvel da estrutura analítica 
do projeto 

12 Pessoas matenas de consumo e 
equpamertos necessários para a 
teanzaçfto da atividade 

14 Diagrama com atividades 
representadas por setas que 
ligam im estado moal a um 
estado fmal (sigla) 

15 Atividades retaoonadas 
diretamente com a açâo dertro do 
projeto 

17 Técnica de reduzir a duraçao do 
projeto através de adiantamentos 


19 Processo de coneuiamerto de 
recursos super alocados 

20 Todo resr/tado físico obtido na 
conclusão do projeto 

21 Exame anal tico de modo a avahar 
se o resultado obtido estâ em 
conformidade com o previsto 

23 Folga de tempo de ima atividade 
de modo a nâo provocar nenhum 
atraso na atmdade sucessora 

24 Repire se nta um pengo ou 
possibilKtade de pengo que pode 
ser gerado peta alternativa 
durarte sua implantação 


Down 

1 Diagrama que utiliza 
barras horizontais, 
colocadas dentro de uma 
escala de tempo 

2 Representa um evento, 
ou condição, que marca 
a execução de um grupo 
de atividades 
relacionadas entre si 

3 Problemas que nào 
possuem uma única 
solução determinada e 
clara 

4 Processo onde a duraçáo 
de cada atividade é 
calculada através da 
estimativa da duração 
otimista, pessimista e 
mais provável da 
atividade 

5 Técnica de estruturação 
do escopo do projeto 

7 Área de conhecimento do 
PMI onde ocorre a 
Seleção de Fornecedores 

10 Ocorre em segmda a 
criação da declaração de 
escopo 

13 Representa a qualidade 
intrínseca daquela 
alternativa dentro do 
projeto 

16 Fator ambiental na 
criação de alternativas 

18 Custo Orçado do 
Trabalho Agendado ou 
BCWS 

22, Representação íormal 
daquilo que se quer 
atingir com o térmmo de 
um projeto 


Resposta* dsponívers no frial do livro - Anexo II 





- ANEXO I - UMA NOVA VISÃO DO PMBOK 

GUIDE 2000 


Trabalho apresentado em novembro de 2001 durante o 29 th Annual Project Management Institute 

Seminars & SymposiumemNashville. Original em inglês. 

Esse trabalho serviu como base para as mudanças propostas pelo PMI para o PMBOK 4 a Edição, 
onde o capítulo 3 é apresentado por grupo de processos e não por área de conhecimento. 



A New Approach to PMBOK® Guide 2000 
Ricardo Viana Vargas, PMP 


Introduction 

This work puts forward a new approach to PMBOK® Guide in which the thirty-nine processes are 
organized in five groups: initiation, planning, executing, controlling and closing process. This 
arrangement suggests a chronologically structured, more didactic view, which has been successfülly 
tested in two PM classes in Brazil, instead of the former organization in nine Knowledge Areas. This 
approach is also useful to PMP exam preparation where two hundred questions are divided into 
process groups rather than knowledge areas. 


PMBOK® Guide 2000 

The PMBOK® Guide is nowadays the most important reference document about the Project 
Management Body of Knowledge. It was defined in 1987 as "all those topics, subject areas and 
intellectual processes which are involved in the application of sound management principies to ... 
projects". The guide is distributed by PMI, free of charge, with more than 640,000 copies placed in 
circulation worldwide (March 2001). As established in the guide, "the primary purpose of this 
document is to identify and describe that subset of the PMBOK® which is generally accepted. 
Generally accepted means that the knowledge and practices described are applicable to most projects 
of the time, and that there is widespread consensus about their value and usefülness" (PMBOK® 
Guide, 2000 Edition). According to the purpose of the guide, it is essential to ha ve a logical and 
coherent organization directly aimed at the process groups in order to facilitate the understanding of 
the chronology of Project Management processes (Exhibit 01). However, it does not mean that the 
knowledge areas should be considered of less importance, as they are crucial for the understanding of 
the multidisciplinary mechanisms related to project management. 







Exhibit 01 - PMBOK based on knowledge areas as opposed to PMBOK based on processes groups 


Project Management Process Groups 

The PMBOK® Guide organizes the Project Management Processes in five groups: initiating 
processes, planning processes, executing processes, controlling processes and closing processes. All 
thirty-nine processes are divided into these five groups and intertwined by the results that they 
achieve (Exhibit 02). The fact that the five process groups are also interlinked creates a dynamic net 
of processes that are repeated and combined in eachphase of the project, and consequently originates 
a process which is not discrete and overlaps itself in different phases and leveis of the project. 
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Exhibit 2 - Thirty-nine processes divided into five groups 


New Structure of PMBOK®’Guide 

The PMBOK® Guide suggested here redefines and reorders the processes innew chapter groups. The 
first two chapters of part 1 (The Project Management Framework) are unchanged. A chapter 3 is now 
built ffom the introductions of the nine chapters of the second part, relating each of the knowledge 
areas and its principal processes, without detailing any process. The previous chapter 3, which 
describes the processes of administration, will now be chapter 4 and will be in the second part of the 



































guide called “The Project Management Process Groups”. All thirty-nine processes will have now 
been distributed in agreement with the phases of the project in which they are used. 

The greatest change would be to place the introductory chapters of each knowledge area in a third 
chapter which gives an overall view of all the processes within each area. The former chapter 3 then 
becomes chapter 4, providing details about Project Management process groups. However, the 
specification of each process group (initiating, planning, executing, controlling and closing), which 
used to be denominated 3.3.X, becomes the introduction of chapters 5 to 9. The new table of contents 
is systematized below: 

Section I-The Project Management Framework 
Chapter 1 Introduction 

1.1. Purpose ofThis Guide 

1.2. What is a Project? 

1.3. What is Project Management? 

1.4. Relationship to Other Management Disciplines 

1.5. Related Endeavors 

Chapter 2 Project Management Context 

2.1. Project Phases and the Project Li ve Cycle 

2.2. Project Stakeholders 

2.3. Organizational Influences 

2.4. Key General Management Skills 

2.5. Social-Economic-Environmental Infl uences 
Chapter 3 Project Management Knowledge Areas 

3.1. Proj ect Integration Management 

3.2. Project Scope Management 

3.3. Project Time Management 

3.4. Project Cost Management 

3.5. Project Quality Management 

3.6. Project HumanResource Management 

3.7. Project Communications Management 

3.8. Proj ect Risk Management 

3.9. Project Procurement Management 

Section II-The Project Management Process Groups 
Chapter 4 Project Management Process 

4.1. Project Processes 

4.2. Process Groups 

4.3. Process Interactions (introduction only) 

4.4. Customizing Process Interactions 

4.5. Mapping of Project Management Process 
Chapter 5 Initiating Process 

5.1. Initiation 

Chapter 6 Planning Process 

6.1. Scope Planning 

6.2. Scope Defini tion 

6.3. Activity Definition 

6.4. Resource Planning 



6.5. Activity Sequencing 

6.6. Activity Duration Estimating 

6.7. Co st Estimating 

6.8. Risk Management Planning 

6.9. Schedule Development 

6.10. Cost Budgeting 

6.11. Quality Planning 

6.12. Organizational Planning 

6.13. Staff Acquisition 

6.14. Communications Planning 

6.15. RiskIdentification 

6.16. Qualitative Risk Analysis 

6.17. Quantitative Risk Analysis 

6.18. Risk Response Planning 

6.19. Procurement Planning 

6.20. Solicitation Planning 

6.21. Project Plan Development 
Chapter 7 Executing Process 

7.1. Proj ect Plan Execution 

7.2. Quality Assurance 

7.3. TeamDevelopment 

7.4. Information Distribution 

7.5. Solicitation 

7.6. Source Selection 

7.7. Contract Administration 
Chapter 8 Controlling Process 

8.1. Performance Reporting 

8.2. Scope Verification 

8.3. Scope Change Control 

8.4. Schedule Control 

8.5. Cost Control 

8.6. Quality Control 

8.7. RiskMonitoring and Control 

8.8. Integrated Change Control 
Chapter 9 Closing Process 

9.1. Contract Closeout 

9.2. Administrative Closure 
Section III-Appendices 
Section IV - Glossary and Index 


With this table of contents a new PMBOK® can easily be built beginning with the reordering of the 
conventional processes without losing any part of the original, that is, without the omission of any of 
the original content. 



Process Interactions 

All 39 processes are linked by their inputs and outputs. In the New Approach to PMBOK® Guide the 
system for numbering the processes serves to focus on the process groups and not the knowledge 
areas. This makes the focus of each of the processes continuous for a period of time while it is not 
necessarily linked to one of the nine knowledge areas. 

The numeration of the inputs, tools and techniques and outputs of the conventional PMBOK® is given 
according to a sequence of numerais in which the first number of the sequence represents the 
knowledge area, the second number, the sequence of the process within the knowledge area, the third, 
the type of data (inputs, tools and techniques or outputs) and the fourth is the sequential of data within 
the type (Exhibit 03). 
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Exhibit 3 - Nomenclature of the conventional PMBOK and example of the first Tools and Techniques of the Integration Process 
“Project Plan Development” denominated “Project planning methodology” 


In the New Approach to PMBOK® Guide, the numeration of the inputs, tools and techniques and 
outputs is given by a sequence of numerais similar to that of the conventional PMBOK®, although the 
first number of the sequence represents the process group, the second number, the sequence of the 
process within the process group, the third, the type of data (inputs, tools and techniques or outputs) 
and the fourth is the sequential of the data within the type (Exhibit 04 and 05). 


TEMPLATE 

X . Y . C . D - Process data 


EXAMPLE 

6.212.1 - Project planning methodology 


X -Procew Group 

5 - rt o:no 

6 - Ram u 

7 - Btea^in ST :-aE» 
l - ConTolng *o:as 

9 - OOS*1Q ROSS» 

Y - Process Number tn«K>» each Prece es Group 

1 frat) » 21 (Perrtng 

C- Date Type 

1 - roa 

I - TbOS 5X TCMM 
3-Cjau: 

D - Data Numfrsr mau» aacti Data Ty pe 

1 1010 


X -PT 0096 * Group 

6 - Proa £SS 


Y-Procew NumbertnaK» each Knowteope Area 

21 - 'toerr, — rs*. p ot. *o P ro a» 

C- DataType 

2 - Too s aro Tfcírujje 


D - Data NumPer inatos eacti Data Type 
1 - - rs: Tbo ano Tfemoje 


Exhibit 4 - Nomenclature of the New Approach to PMBOK Guide and example of the first Tools and Techniques of the Integration 








Process “Project Plan Development” denominated “Project planning methodology” 
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Exhibit 5 - Example of the new numbering system for inputs, tools and techniques and outputs for the Integration Process “Project Plan 
Development” and a comparison with the conventionalPMBOK numbering system 


Results Achieved in Pilot Training Courses Using the New Structure 

With a view to evaluating the New Approach to PMBOK® Guide, an experiment with two thirty- 
student classes of Project Management was held in a multinational IT company in Brazil, according to 
the specifications below: 

• 100% of the evaluated participants belonged to the same company 

• 80% of the participants in each group were engineers (24 in each group) 

• 20% of the participants in each group had a degree in Administration (06 in each group) 

• 100% of the participants were unaware of the existence of PMBOK® Guide and considered 
their knowledge of Project Management to be low or null. 

• The instruetor was the same for both classes and the time and weekdays of the training were 
the same for both with a lag of 1 week between the classes. The instruetor prepared a very 
similar teaching methodology for each of the two groups, including the same exercises and tests. 

In order to select the participants for each group, an equal division based on their professional 
backgrounds was part of the chosen procedure. A forty question test covering Project Management in 
general was also applied for the purpose of having groups as homogeneous as possible and therefore 
avoiding flaws in the evaluation. Each group attended a 32-hour training program covering the 
PMBOK® processes with no absence. The first group's course followed the approach and order of 
the conventional PMBOK® in which the subjects are divided into knowledge areas, whereas the 
second group was exposed to the New Approach to PMBOK®, having the subjects divided into 
processes. 
















At the end of the program a new forty-question test on Project Management was administered to the 
two groups. The results achieved were as follows: 

Group A-Conventional PMBOK® Guide 
Average: 26.97 

Standard Deviation: 3.56 (13.2%) 

Highest score: 32 
Lowest score: 22 
Median: 26.5 
Mode: 26 


Group B-New Approach to PMBOK® Guide 
Average: 32.63 

Standard Deviation: 2.51 (7,70%) 

Highest score: 37 
Lowest score: 28 
Median: 33 
Mode: 30 


The evaluation results suggest that The New Approach to PMBOK® led to an increase of about 20% 
in the final scores, with lower standard deviation. They also suggest significant gains when taken into 
consideration the questionnaire filled out by the participant, which reveals that the major difficulty 
concerning the present PMBOK® is its analytical structure aimed at being used as reference material 
rather than as a means of initial learning. 

After the results had been tabulated, all participants were invited to evaluate the two versions as a 
group. This evaluation shows that the New Approach to PMBOK® holds the following advantages: 

• It makes the reading of PMBOK® sequential, avoiding explaining and analyzing future process 
groups inprevious phases of the guide. 

• The visualization of the relation between the processes becomes easier as the new structure 
clearly identifies the relation between certain succeeding process inputs and previous process 
outputs. 

• The new structure does not leave out any of the content or standards previously established by 
the original PMBOK® Guide. 

These results suggest an apparent gain according to the scores obtained by these participants, although 
the study must be deepened with other groups and other companies to produce a working result that is 
more scientifically proven 


Conclusions 



This New Approach to the PMBOK® Guide does not come as a substitute for the original PMBOK® 
Guide, but as a new view of the processes. Its objective is to facilitate professionaPs learning of the 
Project Management Body of Knowledge. Professionals who are not familiar with Project 
Management and those who are preparing for the PMP exam are the target public of the suggested 
approach. A unique problem must be considered in regard to the numbering system. In the New 
Approach to the PMBOK" Guide, all of the entrance elements, tools, and exits for each process are 
numbered according to the phase of the project and not according the knowledge area, which could 
create some discomfort in those professionals who already know and use the conventional PMBOK® 
Guide with a certain levei of confidence. 
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- ANEXO II - RESPOSTAS DAS PALAVRAS 

CRUZADAS 



Conceitos Básicos de Projetos 



Across 

4. Uma realidade atual 

6 Vários projetos estão 
reunidos em um 
conjunto de benefícios 

7. Exemplo de área de 
aplicabilidade do 
gerenciamento de 
projetos 

8 Não é um projeto 

9. Exemplo de forma de 
pressão externa para 
utilização do 
gerenciamento de 
projetos 

10. Caracteristica que 
determina o produto 
único do projeto 


Down 

1 Está diretamente 
relacionado ao 
sucesso do projeto 

2 Não está relacionado 
ao sucesso do projeto 

3. Característica 
fundamental de um 
projeto 

5. Sua falta favorece o 
fracasso do projeto 





Ciclo de Vida de um Projeto 
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Across 

3. Com relação a 
velocidade de 
desenvolvimento, todo 
projeto tem um inicio 

8. Cenário onde as 
mudanças são 
benéficas 

9. Fase de definição 

10 Regra geral, quanto 

maior, maior é a 
performance 


Down 

1 Ponto máximo de 
esforço no projeto 
2. É o resultado de um 
detalhamento 
excessivo do escopo 
4 Fator determinado a 
partir da relação entre 
escopo e qualidade 
5. Fase que materializa 
tudo aquilo que foi 
planejado 
anteriormente 
6 Prejudica a 

performance de um 
projeto 

7. Forma gráfica da 
inter-relação entre P, 
CeT 




Áreas do PMBOK Guide 3rd Edition 



1. Exemplo de custo da 
nào conformidade 
5 Um elemento do plano 
do projeto 
6. Tipo de perfil 

requerido na execução 
do projeto 

8 Documento legal que 
reconhece a existência 
de um projeto 
10. Responsável por 
produzir uma 
informação clara 


Análise que avalia e 
determina o impacto 
dos riscos e a 
probabilidade dos 
riscos identificados 

14 Processo de 
gerenciamento de 
custos 

15 Um dos tipos de 
análise de riscos 

16. Fluxo de comunicação 
bilateral 

18 Um dos processos do 
gerenciamento de 
tempo 


Across 

13: 


Down 

[2. Devem estar contidas na 
declaração de escopo 

3 Área que garante que tudo 
está integrado em um todo 
único 

4 Exemplo de custo de 
conformidade 

7. Processo que se concentra 
no monitoramento dos 
resultados do projeto para 
determinar se eles estão 
atendendo a todos os 
padrões de qualidade 
definidos 

9 Conjunto de características 
funcionais do produto 

11. Conceito que reconhece 
que o mundo está em 
constante mutação 

12. Contrato com menor risco 
para o comprador 

17. Total do áreas do 

conhecimento cobertas pelo 
PMBOK 

19. Uma das áreas mais 
visíveis do gerenciamento 
de projetos 




Preparando a Organização 




1. Escritório de projeto 
de esfera 
departamental 

3. Uma problema a ser 
administrado na 
estrutura matricial 

4. Centro de 
informações e 
controle do projeto 
(sigla) 

5. Alocação do 
coordenador do 
projeto nas estruturas 
matriciais leves 


Across 

2. Responsável pela 
administração do 
projeto nas estruturas 
funcionais 

4. Escritório de projeto 
separado das 
operações da empresa, 
destinados ao 
gerenciamento de um 
projeto ou programa 
especifico 

6 Alocação da equipe 
administrativa do 
projeto nas 
organizações por 
projetos 





Gerente de Projetos e Conflitos 



Across 

1. Aspecto positivo dos 
conflitos 

4 Pilar do gerente de 
projetos 

7. Fonte de conflito nos 
projetos 

8 Tipo de conflito a ser 
evitado de todas as 
formas em um projeto 

9. Uma habilidade no 
gerenciamento do time 
do gerente de projetos 


Down 

2 Erro ao se selecionar 
um gerente de projetos 

3. Habilidade do caráter 
do gerente de projetos 

5, Uma habilidade de 
comunicação do 
gerente de projetos 

6. Aspecto negativo dos 
conflitos 




Modelo Geral de Projetos 


G 



6 Forma òe se cnar altematvas de 
condução do projeto 

8 Vanação de custos do projeto 
utilizando a análise de valor 
agregado 

9 Resultados flsioos, ou 
semi-produtos obtidos ao longo 
do projeto 

11 Produto a ser entregue no mais 
baixo nível da estrutura analítica 
do projeto 

12 Pessoas, materiais de consumo e 
equipamentos necessários para a 
realização da atividade 

14 Diagrama oom atividades 
representadas por setas que 
ligam um estado inicial a um 
estado final (sigla) 

15 Atividades relacionadas 
diretamente com a ação dentro do 
pro)eto 

17 Técnica de reduzir a duração do 
projeto através de adiantamentos 


19 Processo de conciiiamento de 
recursos super alocados 

20 Todo resuilado fisico obtido na 
conclusão do projeto 

21 Exame analítico de modo a avaliar 
se o resultado obtido está em 
conformidade com o previsto nas 
su 

23 Folga de tempo de uma atividade 
de modo a nâo provocar nenhum 
atraso na atividade sucessora 

24 Representa um perigo, ou 
possibilidade de perigo, que pode 
ser gerado pela alternativa 
durante sua Implantação 


Down 

1. Diagrama que utiliza 
barras horizontais, 
colocadas dentro de uma 
escala de tempo 

2. Representa um evento, 
ou condição, que marca 
a execução de um grupo 
de atividades 
relacionadas entre si 

3. Problemas que não 
possuem uma única 
solução determinada e 
clara 

4 Processo onde a duração 
de cada atividade é 
calculada através da 
estimativa da duração 
otimista, pessimista e 
mais provável da 
atividade 

5. Técnica de estruturação 
do escopo do projeto 

7. Área de conhecimento do 
PMI onde ocorre a 
Seleção de Fornecedores 

10. Ocorre em seguida a 
criação da declaração de 
escopo 

13. Representa a qualidade 
intrínseca daquela 
alternativa dentro do 
projeto 

16. Fator ambiental na 
cnação de alternativas 

18. Custo Orçado do 
Trabalho Agendado ou 
BCWS 

22. Representação formal 
daquilo que se quer 
atingir com o término de 
um projeto 


ANEXO III - TRADUÇÃO DO INGLÊS PARA O 







PORTUGUÊS DOS PRINCIPAIS TERMOS 

Baseado no PMBOK Guide ® 4 a Edição, onde o glossário completo está disponível 



Accept - Aceitar 

Acceptance - Aceitação 

Acceptance Criteria - Critérios de aceitação 

Acquire Project Team- Contratar ou mobilizar a equipe do projeto 

Activity - Atividade 

Activity Attributes - Atributos da atividade 
Activity Code - Código da atividade 
Activity Definition - Definição da atividade 
Activity Description (DA) - Descrição da atividade 
Activity Duration - Duração da atividade 

Activity Duration Estimating - Estimativa de duração da atividade 
Activity Identifier- Identificador da atividade 
Activity List - Lista de atividades 

Activity Resource Estimating - Estimativa de recursos da atividade 
Activity Sequencing - Sequenciamento de atividades 
Activity-on-Arrow (AOA) - Atividade na seta (ANS) 

Activity-on-Node (AON) - Atividade no nó (ANN) 

Actual Cost (AC) - Custo real (CR) 

Actual Cost of Work Performed (ACWP) - Custo real do trabalho realizado (CRTR) 

Actual Duration - Duração real 

Actual Finish Date (AF) - Data de término real (TR) 

Actual Start Date (AS) - Data de início real (IR) 

Analogous Estimating - Estimativa análoga 
Application Are a - Área de aplicação 
Apportioned Effort (AE) - Esforço distribuído (ED) 

Approval - Aprovação 
Approve - Aprovar 

Approved Change Re que st - Solicitação de mudança aprovada 
Arrow - Seta 

Arrow Diagramming Method (ADM) - Método do diagrama de setas (MDS) 

As-of Date - Até a presente data 

Assumptions - Premissas 

Assumptions Analysis - Análise das premissas 

Authority - Autoridade 

Backward Pass - Caminho de volta 

Bar Chart - Gráfico de barras 

Baseline - Linha de base 



Baseline Finish Date - Data de base de término 

Baseline Start Date - Data de base de início 

Bill of Materials (BOM) - Lista de preço de materiais (LPM) 

Bottom-up Estimating - Estimativa "bottom-up" 

Brainstorming - Brainstorming [Técnica] 

Budget - Orçamento 

Budget at Completion (BAC) - Orçamento no término (ONT) 

Budgeted Cost of Work Performed (BCWP) - Custo orçado do trabalho realizado (COTR) 

Budgeted Cost of Work Scheduled (BCWS) - Custo orçado do trabalho agendado (COTA) 

Buffer - Buffer 

Buyer - Comprador 

Calendar Unit - Unidade de calendário 

Change Control - Controle de mudanças 

Change Control Board (CCB) - Comitê de controle de mudanças (CCM) 

Change Control System - Sistema de controle de mudanças 

Change Re que st - Solicitação de mudança 

Chart of Accounts - Plano de contas 

Charter - Termo de abertura 

Checklist - Lista de verificação 

Claim - Reclamação 

Close Project - Encerrar o projeto 

Closing Processes - Processos de encerramento 

Code of Accounts - Código de contas 

Co-location - Agrupamento 

Common Cause - Causa comum 

Communication - Comunicação 

Communication Management Plan- Plano de gerenciamento das comunicações 
Communications Planning - Planejamento das comunicações 
Compensation - Compensação 
Component - Componente 

Configuration Management System - Sistema de gerenciamento de configuração 
Constraint - Restrição 
Contingency - Contingência 

Contingency Allowance - Provisão para contingências 
Contingency Reserve - Reserva para contingências 
Contract - Contrato 

Contract Administration - Administração de contrato 



Contract Closure - Encerramento do contrato 

Contract Management Plan- Plano de gerenciamento de contratos 

Contract Statement of Work (SOW) - Declaração do trabalho (DT) do contrato 

Contract Work Breakdown Structure (CWBS) - Estrutura analítica do projeto contratado (EAPC) 

Control - Controle 

Control Account (CA) - Conta de controle (CC) 

Control Account Plan (CAP) - Plano de contas de controle (PCC) 

Control Chart - Gráfico de controle 
Control Limits - Limites de controle 
Controlling - Controlar 
Corre ctive Action- Ações corretivas 
Cost - Custo 

Cost Baseline - Linha de base dos custos 

Cost Budgeting - Orçamentação 

Cost Control - Controle de custos 

Cost Estimating - Estimativa de custos 

Cost Management Plan - Plano de gerenciamento de custos 

Cost of Quality (COQ) - Custo da qualidade (CDQ) 

Cost Performance Index (CPI) - índice de desempenho de custos (IDC) 

Cost Variance (CV) - Variação de custos (VC) 

Cost-Plus-Fee (CPF) - Custo mais remuneração (CMR) 

Cost-Plus-Fixed-Fee (CPFF) Contract - Contrato de custo mais remuneração fixa (CMRF) 

Cost-Plus-Incentive-Fee (CPIF) Contract - Contrato de custo mais remuneração de incentivo 
(CMRI) 

Cost-Plus-Percentage of Cost (CPPC) - Custo mais percentual do custo (CMPC) 
Cost-Reimbursable Contract - Contrato de custos reembolsáveis 
Crashing - Compressão 

Create WBS (Work Breakdown Structure) - Criar EAP (Estrutura analítica do projeto) 

Criteria - Critérios 

Criticai Activity - Atividade crítica 

Criticai Chain Method - Método da cadeia crítica 

Criticai Path - Caminho crítico 

Criticai Path Method (CPM) - Método do caminho crítico (CPM) 

Current Finish Date - Data de término atual 
Current Start Date - Data de início atual 
Customer - Cliente 

Data Date (DD) - Data dos dados (DD) 



Date - Data 

Decision Tree Analysis - Análise da árvore de decisão 
Decompose - Decompor 
Decomposition - Decomposição 
Defect - Defeito 

Defect Repair - Reparo de defeito 
Deliverable - Produto 
Delphi Technique - Técnica Delphi 
Dependency - Dependência 
Design Review - Revisão de projeto 

Develop Project Charter - Desenvolver o termo de abertura do projeto 

Develop Project Management Plan - Desenvolver o plano de gerenciamento do projeto 

Develop Project Te am- Desenvolver a equipe do projeto 

Direct and Manage Project Execution - Orientar e gerenciar a execução do projeto 

Discipline - Disciplina 

Discrete Effort - Esforço distinto 

Document - Documento 

Documented Procedure - Procedimento documentado 
Dummy Activity - Atividade fantasma 
Duration (DU or DUR) - Duração (DU ou DUR) 

Early Finish Date (EF) - Data de término mais cedo (TMC) 

Early Start Date (ES) - Data de início mais cedo (IMC) 

Earned Value (EV) - Valor agregado (VA) 

Earned Value Management (EVM) - Gerenciamento de valor agregado (GVA) 

Earned Value Technique (EVT) - Técnica do valor agregado (TVA) 

Effort - Esforço 
Enterprise - Empresa 

Enterprise Environmental Factors - Fatores ambientais da empresa 
Estimate - Estimativa 

Estimate at Completion (EAC) - Estimativa no término (ENT) 

Estimate to Complete (ETC) - Estimativa para terminar (EPT) 

Event - Evento 

Exception Report - Relatório de exceções 
Execute - Executar 
Executing - Execução 

Executing Processes - Processos de execução 
Execution - Execução 



Expected Monetary Value (EMV) Analysis - Análise do valor monetário esperado (VME) 
Expert Judgment - Opinião especializada 

Failure Mode and Effect Analysis (FMEA) - Análise de modos e efeitos de falha (FMEA) 

Fast Tracking - Paralelismo 

Finish Date - Data de término 

Finish-to-Finish (FF) - Término para término (TT) 

Finish-to-Start (FS) - Término para início (TI) 

Firm-Fixed-Príce (FFP) Contract - Contrato de preço fixo garantido (PFG) 

Fixed-Price or Fump-Sum Contract - Contrato de preço fixo ou preço global 

Fixed-Price-Incentive-Fee (FPIF) Contract - Contrato de preço fixo com remuneração 
incentivo (PFRI) 

Float - Folga 

Flowcharting - Elaboração de fluxogramas 
Forecasts - Previsões 
Forward Pass - Caminho de ida 
Free Float (FF) - Folga livre (FL) 

Functional Manager - Gerente funcional 
Functional Organization - Organização funcional 
Funds - Fundos 

Gantt Chart - Gráfico de Gantt 
Goods - Bens 
Grade - Grau 

Ground Rules - Regras básicas 

Hammock Activity - Atividade sumarizadora 

Historical Information - Informações históricas 

Human Resource Planning - Planejamento de recursos humanos 

Imposed Date - Data imposta 

Influence Diagram - Diagrama de influência 

Influencer - Influenciador 

Information Distribution - Distribuição das informações 

Initiating Processes - Processos de iniciação 

Initiator - Iniciador 

Input - Entradas 

Inspection - Inspeção 

Integral| - Integral 

Integrated - Integrado 

Integrated Change Control - Controle integrado de mudanças 



Invitation for Bid (IFB) - Convite para licitação (CONV) 

Issue - Problema 
Knowledge - Conhecimento 

Knowledge Are a Process - Processo de área de conhecimento 

Knowledge Area, Project Management - Área de conhecimento, Gerenciamento de projetos 
Lag - Espera 

Late Finish Date (LF) - Data de término mais tarde (TMT) 

Late Start Date (LS) - Data de início mais tarde (IMT) 

Latest Revised Estimate - Ultima estimativa revisada 

Lead - Antecipação 

Lessons Learned - Lições aprendidas 

Lessons Learned Knowledge Base - Base de conhecimento de lições aprendidas 
Levei of Effort (LOE) - Nível de esforço (NDE) 

Leveling - Nivelamento 
Life Cycle - Ciclo de vida 
Log - Registro 
Logic - Lógica 

Logic Diagram - Diagrama lógico 
Logical Relationship - Relacionamento lógico 
Manage Project Team- Gerenciar a equipe do projeto 
Manage Stakeholders - Gerenciar as partes interessadas 
Master Schedule - Cronograma mestre 
Materiel - Material 

Matrix Organization- Organização matricial 
Methodology - Metodologia 
Milestone - Marco 

Milestone Schedule - Cronograma de marcos 
Monitor - Monitorar 

Monitor and Control Project Work - Monitorar e controlar o trabalho do projeto 
Monitoring - Monitoramento 

Monitoring and Controlling Processes - Processos de monitoramento e controle 
Monte Cario Analysis - Simulação de Monte Cario 
Near-Critical Activity - Atividade quase crítica 
Network - Rede 

Network Analysis - Análise de rede 
Network Logic - Lógica de rede 
Network Loop - Loop de rede 



Network Open End - Terminação aberta na rede 
Network Path - Caminho de rede 
Networking - Networking [Técnica] 

Node-Nó 
Objective - Objetivo 
Operations - Operações 
Opportunity - Oportunidade 
Organization - Organização 
Organization Chart - Organograma 

Organizational Breakdown Structure (OBS) - Estrutura Analítica Organizacional (EAO) 
Organizational Process Assets - Ativos de processos organizacionais 
Original Duration (OD) - Duração original (DO) 

Output - Saídas 

Parametric Estimating - Estimativa paramétrica 
Pareto Chart - Diagrama de Pareto 
Path Convergence - Convergência de caminhos 
Path Divergence - Divergência de caminhos 

Percent Complete (PC or PCT) - Percentual completo (PC ouPCT) 

Perform Quality Assurance (QA) - Realizar a garantia da qualidade (GQ) 

Perform Quality Control (QC) - Realizar o controle da qualidade (CQ) 

Performance Measurement Baseline - Linha de base da medição de desempenho 

Performance Reporting - Relatório de desempenho 

Performance Reports - Relatórios de desempenho 

Performing Organization - Organização executora 

Phase - Fase 

Plan Contracting - Planejar contratações 

Plan Purchases and Acquisitions - Planejar compras e aquisições 
Planned F ini sh Date (PF) - Data de término planejada (TP) 

Planned Start Date (PS) - Data de início planejada (IP) 

Planned Value (PV) - Valor planejado (VP) 

Planning Package - Pacote de planejamento 
Planning Processes - Processos de planejamento 
Portfolio - Portfólio 

Portfolio Management - Gerenciamento de portfólios 
Position Description - Descrição de cargo 
Practice - Prática 

Precedence Diagramming Method (PDM) - Método do diagrama de precedência (MDP) 



Precedence Relationship - Relação de precedência 
Predecessor Activity - Atividade predecessora 
Preventive Action - Ação preventiva 

Probability and Impact Matrix - Matriz de probabilidade e impacto 

Procedure - Procedimento 

Process - Processo 

Process Group - Grupo de processos 

Procure me nt Documents - Documentos de aquisição 

Procure me nt Management Plan- Plano de gerenciamento de aquisições 

Product - Produto 

Product Life Cycle - Ciclo de vida do produto 
Product Scope - Escopo do produto 

Product Scope Description- Descrição do escopo do produto 
Program - Programa 

Program Management - Gerenciamento de programas 
Program Management Office (PMO) - Escritório de programas 
Progressive Elaboration - Elaboração progressiva 
Project - Projeto 

Project Calendar - Calendário de projeto 
Project Charter - Termo de abertura do projeto 

Project Communications Management - Gerenciamento das comunicações do projeto 
Project Cost Management - Gerenciamento de custos do projeto 

Project Human Resource Management - Gerenciamento de recursos humanos do projeto 
Project Initiation - Iniciação do projeto 

Project Integration Management - Gerenciamento de integração do projeto 

Project Life Cycle - Ciclo de vida do projeto 

Project Management (PM) - Gerenciamento de projetos (GP) 

Project Management Body of Knowledge (PMBOK®) - Conjunto de conhecimentos em 
gerenciamento de projetos 

Project Management Information System (PMIS) - Sistema de informações do gerenciamento de 
projetos (SIGP) 

Project Management Knowledge Are a - Área de conhecimento em gerenciamento de projetos 

Project Management Office (PMO) - Escritório de projetos 

Project Management Plan - Plano de gerenciamento do projeto 

Project Management Process - Processo de gerenciamento de projetos 

Project Management Process Group - Grupo de processos de gerenciamento de projetos 

Project Management Professional (PMP®) - Profissional de gerenciamento de projetos 



Project Management Software - Software de gerenciamento de projetos 
Project Management System - Sistema de gerenciamento de projetos 
Project Management Te am- Equipe de gerenciamento de projetos 
Project Manager (PM) - Gerente de projetos (GP) 

Project Organization Chart - Organograma do projeto 
Project Phase - Fase do projeto 

Project Process Groups - Grupos de processos do projeto 

Project Procure me nt Management - Gerenciamento de aquisições do projeto 

Project Quality Management - Gerenciamento da qualidade do projeto 

Project Risk Management - Gerenciamento de riscos do projeto 

Project Schedule - Cronograma do projeto 

Project Schedule Network Diagram - Diagrama de rede do cronograma do projeto 
Project Scope - Escopo do projeto 

Project Scope Management - Gerenciamento do escopo do projeto 

Project Scope Management Plan- Plano de gerenciamento do escopo do projeto 

Project Scope State me nt - Declaração do escopo do projeto 

Project Sponsor - Patrocinador do projeto 

Project Stakeholder- Partes interessadas no projeto 

Project Summary Work Breakdown Structure (PSWBS) - Estrutura analítica do resumo 
projeto (EARP) 

Project Team- Equipe do projeto 
Project TeamDirectory - Lista da equipe do projeto 
Project TeamMembers - Membros da equipe do projeto 
Project Time Management - Gerenciamento de tempo do projeto 
Project Work - Trabalho do projeto 
Projectized Organization - Organização por projeto 
Qualitative Risk Analysis - Análise qualitativa de riscos 
Quality - Qualidade 

Quality Management Plan - Plano de gerenciamento da qualidade 
Quality Planning - Planejamento da qualidade 
Quantitative Risk Analysis - Análise quantitativa de riscos 

Requirements Traceability Matrix (RTM) - Matriz de Rastreamento de Requisitos (MRR) 

Regulation - Regulamento 

Reliability - Confiabilidade 

Remaining Duration (RD) - Duração restante (DR) 

Re que st for Information - Solicitação de informações 
Request for Proposal (RFP) - Solicitação de proposta (SDP) 



Re que st for Quotation (RFQ) - Solicitação de cotação (SDC) 

Request Seller Responses - Solicitar respostas de fornecedores 
Requeste d Change - Mudança solicitada 
Requirement - Requisito 
Reserve - Reserva 

Reserve Analysis - Análise das reservas 
Residual Risk - Risco residual 
Resource - Recurso 

Resource Breakdown Structure (RBS) - Estrutura analítica dos recursos (EAR) 

Resource Calendar- Calendário de recurso 

Resource Histogram - Histograma de recursos 

Resource Leveling - Nivelamento de recursos 

Resource Planning - Planejamento de recursos 

Resource-Constrained Schedule - Cronograma restrito por recursos 

Resource-Limited Schedule - Cronograma limitado por recursos 

Responsibility Assignment Matrix (RAM) - Matriz de responsabilidades (MR) 

Result - Resultado 

Retainage - Retenção 

Re work - Retrabalho 

Risk - Risco 

Risk Acceptance - Aceitação dos riscos 
Risk Avoidance - Prevenção de riscos 

Risk Breakdown Structure (RBS) - Estrutura analítica dos riscos (EAR) 

Risk Category - Categoria de risco 

Risk Database - Banco de dados de riscos 

Risk Identification - Identificação de riscos 

Risk Management Plan - Plano de gerenciamento de riscos 

Risk Management Planning - Planejamento do gerenciamento de riscos 

Risk Mitigation - Mitigação de riscos 

Risk Monitoring and Control - Monitoramento e controle de riscos 
Risk Register - Registro de riscos 

Risk Response Planning - Planejamento de respostas a riscos 
Risk Transference - Transferência de riscos 
Role - Função 

Rolling Wave Planning - Planejamento em ondas sucessivas 
Root Cause Analysis - Análise da causa-raiz 
Schedule - Cronograma 



Schedule Activity - Atividade do cronograma 

Schedule Analysis - Análise do cronograma 

Schedule Compression- Compressão do cronograma 

Schedule Control - Controle do cronograma 

Schedule Development - Desenvolvimento do cronograma 

Schedule Management Plan- Plano de gerenciamento do cronograma 

Schedule Milestone - Marco do cronograma 

Schedule Model- Modelo de cronograma 

Schedule Network Analysis - Análise de rede do cronograma 

Schedule Performance Index (SPI) - índice de desempenho de prazos (IDP) 

Schedule Variance (SV) - Variação de prazos (VPR) 

Schedule d Finish Date (SF) - Data de término agendada (TA) 

Schedule d Start Date (SS) - Data de início agendada (IA) 

Scope - Escopo 

Scope Baseline - Linha de base do escopo 
Scope Change - Mudanças do escopo 
Scope Control - Controle do escopo 
Scope Creep - Aumento do escopo 
Scope Definition- Definição do escopo 
Scope Planning - Planejamento do escopo 
Scope Verification - Verificação do escopo 
S-Curve - Curva S 
Secondary Risk - Risco secundário 
Select Sellers - Selecionar fornecedores 
Seller - Fornecedor 

Sensitivity Analysis - Análise de sensibilidade 
Service - Serviço 

Should-Cost Estimate - Estimativa de custos exequíveis 
Simulation - Simulação 
Skill - Habilidade 
Slack-Folga 

Special Cause - Causa especial 
Specification - Especificação 
Specification Limits - Limites de especificação 
Sponsor - Patrocinador 

Staffing Management Plan - Plano de gerenciamento de pessoal 
Stakeholder - Partes interessadas 



Standard - Norma 

Start Date - Data de início 

Start-to-Finish (SF) - Início para término (IT) 

Start-to-Start (SS) - Início para início (II) 

Statement of Work (SOW).- Declaração do trabalho (DT) 

Strengths, Weaknesses, Opportunities, and Threats (SWOT) Analysis - Análise dos pontos 
fortes e fracos, oportunidades e ameaças 

Subnetwork - Sub-rede 

Subphase - Subfase 

Subproject - Subprojeto 

Successor- Sucessor 

Successor Activity - Atividade sucessora 

Summary Activity - Atividade de resumo 

System - Sistema 

Target Completion Date (TC) - Data alvo para término (AT) 

Target Finish Date (TF) - Data alvo para término (AT) 

Target Schedule - Cronograma alvo 

Target Start Date (TS) - Data alvo para início (AI) 

Task - Tarefa 

Team Members - Membros da equipe 

Technical Performance Measurement - Medição de desempenho técnico 
Technique - Técnica 
Template - Modelo 
Threat - Ameaça 

Three-Point Estimate - Estimativa de três pontos 
Threshold - Limite 

Time and Material (T&M) Contract - Contrato por tempo e material 
Time-Now Date - Data atual 

Time-Scaled Schedule Network Diagram - Diagrama de rede do cronograma com escala de tempo 

Tool - Ferramenta 

Total Float (TF) - Folga total (FT) 

Total Quality Management (TQM) - Gerenciamento da qualidade total (GQT) 

Trend Analysis - Análise das tendências 
Triggers - Gatilhos 
Triple Constraint - Restrição tripla 
User - Usuário 
Validation - Validação 



Value Engine ering (VE) - Engenharia de valor (EV) 

Variance - Variação 

Variance Analysis - Análise da variação 
Verification - Verificação 
Virtual Te am- Equipe virtual 
Voice of the Customer - \òz do cliente 
War Room - Sala de comando 
Work - Trabalho 

Work Authorization - Autorização do trabalho 

Work Authorization System - Sistema de autorização do trabalho 

Work Breakdown Structure (WBS) - Estrutura analítica do projeto (EAP) 

Work Breakdown Structure Component - Componente da estrutura analítica do projeto 
Work Breakdown Structure Dictionary - Dicionário da estrutura analítica do projeto 
Work Item - Item de trabalho 
Work Package - Pacote de trabalho 

Work Performance Information - Informações sobre o desempenho do trabalho 
Workaround - Solução alternativa 
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5 Optou-se nesse caso por utilizar o inglês Performance no lugar de Desempenho devido à popularidade do acrônimo PCT. 

Ó © Project Management Institute, A Guide to the Project Management Body ofKnowledge (PMBOK® Guide) - 4a Edição. Material Reproduzido com autorização e permissão do PMI. 

7 Esse artigo foi apresentado no PMI Global Congress em Nashville - Tennessee - EUA e serviu como base para a nova estrutura do 
PMBOK® Guide 4 a edição, onde o terceiro capítulo faz o papel didático de apresentar os processos dentro das fases (grupos de 
processo) e não dentro das áreas de conhecimento. 
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